Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[madbrain]

I have been experiencing a problem with playback latency.
When I put my machine in the power saver profile, I am not able to play a multi-channel SACD ISO without very bad stuttering, even on an 8-core / 3.1 GHz machine.

Here is a video that demonstrates the problem : https://youtu.be/IgdYIkDaNQE . I couldn't find a way to embed it into my post.
1) First, I play in Balanced power profile. Everything is fine :
https://www.youtube.com/watch?v=IgdYIkDaNQE#t=00m01s
CPU usage is in the 20-30% range and the CPU is at 3+ GHz clock.
2) Then, I play in the Power saver profile.
https://www.youtube.com/watch?v=IgdYIkDaNQE#t=01m11s
Things stutter very badly. But CPU usage drops to the <10% range, and the CPU remains clocked in the 1 to 1.5 GHz range only.
You can see on top of the screen that JRiver is "buffering" during the pauses.
3) Then, I try running Prime95, a program that runs all its threads at idle priority. CPU usage goes to 100% and the CPU throttles up to 3+ GHz.

I believe there is a bug here. In the power saver mode, Media center isn't even trying to use the available CPU cycles. It's not starved for disk I/O, it's not starved for RAM, and it's not starved for CPU either. So why does the stuttering happen ?

I spent quite a while investigating this. I even used a program called IOPriority to raise the priority of all Media Center threads to the highest. This did not solve the problem, unfortunately. I think there is likely some kind of algorithm issue in the way the audio is buffered and then fed to the device.

I tried converting the specific track I was playing to DSF format. Same problem. Then I converted it to FLAC. Same problem. Then I converted it to uncompressed WAV . Same problem ! I did not expect that, since there really should be no processing at all when playing WAV.

But then I looked at the WAV file, and I saw that it was a 3.5GB WAV file. That was just one of the 16 tracks of the SACD, but it was almost as big as the entire ISO. Turns out it's still encoded in 358.2 kHz format . So that would still require sampling rate conversion to playback, which has some non-zero cost. I had my DSP studio set to convert this rate to 192 kHz. I switched to 44.1 kHz which is exactly 1/8th of 352.8 kHz . Ie. this is a much less complicated sampling rate conversion. At that point, I was able to play the uncompressed WAV file just fine at under 10% CPU without any stuttering.
I went back to the original SACD ISO, and saw the same thing, no stuttering. All other PCM sampling rates I tried that are valid to bit stream for the nVidia HDMI driver produce the stuttering. 88.2 kHz and 176.4 kHz are not supported. 44.1 kHz is the only thing that works. And it would be silly to listen to SACDs in 44.1 kHz.

I believe there is some kind of problem issue in the sampling rate conversion code that causes this latency/stuttering to happen.
Even with a more complicated conversion to 96 or 192 kHz, and in power saver profile mode, I should still have plenty of CPU cycles available. Media center somehow is not trying to use all the available cycles to complete the sampling rate conversion in time.

Even a non-realtime program that is running at idle priority like Prime95 is able to use nearly all the CPU cycles available, so, I don't think the Windows 10 OS scheduler is at fault here. Admittedly, Prime95 doesn't play audio either.

Hopefully, I have provided enough information to reproduce the bug, but if not, I'll gladly provide more, including the specific SACD ISO if it's needed.

It's been a long time since I wrote realtime audio code. I did so in assembly using interrupts and DMA on the Sound blaster on an 80286 on a Sound Blaster , and even with threads under 32-bit OS/2 in the 1990s. This involved sound mixing and sampling rate conversion, too.  I'm sure the audio system in Windows is quite different than either of these. Maybe the bug is not in JRiver code and some other part of the software stack, perhaps nVidia audio driver, is at fault.  Either way, I would like to know as I would like to get the fix, wherever it may need to come from.

[Hendrik]

There is nothing we can do to influence how your system provides the performance we need. If the system doesn't react fast enough to performance requirements, then audio will cut out.
You can try to increase the buffer size in the audio device settings, maybe it can help with that situation.

Key to audio playback is not necessarily raw sustained power, as filling the audio buffers is not necessarily a continous operation but works in bursts - fill the play out buffer, wait for the device to actually empty some of the buffer, and fill it up again.
In realtime audio playback, you don't have much time to react to the audio device using the data and filling it up again - thats often not a pure performance requirement, but needs the system to react quickly when needed.

One of the things various power saving modes do is letting the system react "slower", which for audio playback is generally a bad idea - especially when resampling, as that of course needs more performance then just copying audio to the audio device.

[madbrain]

There is nothing we can do to influence how your system provides the performance we need. If the system doesn't react fast enough to performance requirements, then audio will cut out.
You can try to increase the buffer size in the audio device settings, maybe it can help with that situation.

Key to audio playback is not necessarily raw sustained power, as filling the audio buffers is not necessarily a continous operation but works in bursts - fill the play out buffer, wait for the device to actually empty some of the buffer, and fill it up again.
In realtime audio playback, you don't have much time to react to the audio device using the data and filling it up again - thats often not a pure performance requirement, but needs the system to react quickly when needed.

One of the things various power saving modes do is letting the system react "slower", which for audio playback is generally a bad idea - especially when resampling, as that of course needs more performance then just copying audio to the audio device.

I'm aware of how audio applications work and the logic of filling buffers and passing them on to the device in a timely fashion. Back in the DOS days this would be managed via interrupts and DMAs. There was much less that could go wrong when going directly to the hardware, but you had to test every single device supported (various SBs, Adlib - even PC speaker which could be hacked to do PCM via very high rate timer interrupt). In modern systems with threads you are at the mercy of the OS, thread scheduler, and drivers, of course.

That said, if I was the author of the application and saw this behavior, I would probably be able to debug it and figure out where things are going bad, at least. Not sure if there is the kind of instrumentation in JRiver to figure that out, as it is not open source. I would be happy to provide a log, if there is.

Which buffer settings did you suggest playing with ? I had prebuffer set to 2s. I put it back to the default 6 seconds. In that case, JRiver plays for a longer period of time uninterrupted, then buffers for an equally long period of time, then plays again, and so on. And you can see the "buffering" message all the time on top. This really suggests to me that the problem is not with feeding buffers that are already full to the audio device, but the fact that the buffers are not full, ie. the calculations are not being done in a timely fashion, for whatever reason, even though there is ample CPU available. Why that might be, I don't know. It's possible that this is related to some sort of serialization in the code. I only looked at overall CPU, but this is an 8 core box. I will try looking at graphs of individual cores and see if it might be maxing one of them. If it's only a single core being maxed, maybe the CPU doesn't throttle up in power savings mode. I will compare the behavior with running one thread in Prime 95 also to see how the graph of the cores behave. Ultimately, without the source code to the app, or reverse engineering it, there is only so much I can figure out of my own, though. It seems to me that there should be something worth investigating, though.

[JimH]

Did you try using the full power of the machine instead of running it in a power saver mode?

Run the benchmark under the Help menu and paste the results here.

Please don't offer programming advice.

[Hendrik]

The buffer i refered to is in the settings under Audio -> Audio Device -> Device settings.. - note that the dialog here is dependent on which audio output you have selected, and not all necessarily offer buffering settings, but most do.

[madbrain]

Did you try using the full power of the machine instead of running it in a power save mode?

Yes. In the other power profiles - "balanced" playback is fine. CPU usage is higher in this modes, also. This is mentioned in my original post above.
I tried in "high performance" power profile, and the behavior is the same as in "balanced" mode for this case.

Run the benchmark under the Help menu and paste the results here.

Will do as soon as I get a chance.

[JimH]

Yes. In the other power profiles - "balanced" playback is fine. CPU usage is higher in this modes, also. This is mentioned in my original post above.
I tried in "high performance" power profile, and the behavior is the same as in "balanced" mode for this case.

That should tell you something.

[madbrain]

The buffer i refered to is in the settings under Audio -> Audio Device -> Device settings.. - note that the dialog here is dependent on which audio output you have selected, and not all necessarily offer buffering settings, but most do.

OK, I will take a look. FYI, I was using WASAPI mode for the nVidia HDMI audio driver. The GT630 GPU is connected to a Yamaha RX-A1000 receiver, itself connected to a Sanyo PLV-Z2000 projector.
Media Center showed the name of the projector as the audio device.

[madbrain]

That should tell you something.

Not nearly as much as what it tells you, unfortunately, since you know the inner workings of the program, and I don't.

[JimH]

Why is that not a good solution?

[madbrain]

Why is that not a good solution?

It's a good workaround, just not a great solution. The fans will spin up more in the other power profiles, which affects the sound. You can actually hear them a little bit in the video if you listen carefully. This is an HTPC with small diameter fans which are always noisier than large ones. The machine will use more electricity as well. I believe there might be some room for improvement in the software stack to make this work better even in the low power profile - just not quite sure which part of the stack can stand to be improved.

[madbrain]

Here is the benchmark data.

First, in power saver profile :

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 14.983 seconds
    Single-threaded floating point math... 6.523 seconds
    Multi-threaded integer math... 2.640 seconds
    Multi-threaded mixed math... 1.010 seconds
Score: 755

Running 'Image' benchmark...
    Image creation / destruction... 1.895 seconds
    Flood filling... 1.309 seconds
    Direct copying... 1.215 seconds
    Small renders... 5.155 seconds
    Bilinear rendering... 2.558 seconds
    Bicubic rendering... 1.314 seconds
Score: 1636

Running 'Database' benchmark...
    Create database... 0.559 seconds
    Populate database... 4.548 seconds
    Save database... 0.451 seconds
    Reload database... 0.154 seconds
    Search database... 4.597 seconds
    Sort database... 4.083 seconds
    Group database... 2.315 seconds
Score: 1287

JRMark (version 22.0.79): 1226

Next, in balanced profile.

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 5.948 seconds
    Single-threaded floating point math... 2.524 seconds
    Multi-threaded integer math... 2.246 seconds
    Multi-threaded mixed math... 1.085 seconds
Score: 1610

Running 'Image' benchmark...
    Image creation / destruction... 1.063 seconds
    Flood filling... 0.728 seconds
    Direct copying... 0.948 seconds
    Small renders... 2.121 seconds
    Bilinear rendering... 1.596 seconds
    Bicubic rendering... 1.222 seconds
Score: 2865

Running 'Database' benchmark...
    Create database... 0.453 seconds
    Populate database... 1.908 seconds
    Save database... 0.202 seconds
    Reload database... 0.087 seconds
    Search database... 1.876 seconds
    Sort database... 1.605 seconds
    Group database... 1.086 seconds
Score: 2979

JRMark (version 22.0.79): 2485

Lastly, high performance profile :

=== Running Benchmarks (please do not interrupt) ===

Running 'Math' benchmark...
    Single-threaded integer math... 6.072 seconds
    Single-threaded floating point math... 2.573 seconds
    Multi-threaded integer math... 2.333 seconds
    Multi-threaded mixed math... 1.035 seconds
Score: 1582

Running 'Image' benchmark...
    Image creation / destruction... 1.070 seconds
    Flood filling... 0.766 seconds
    Direct copying... 1.061 seconds
    Small renders... 2.167 seconds
    Bilinear rendering... 1.633 seconds
    Bicubic rendering... 1.255 seconds
Score: 2766

Running 'Database' benchmark...
    Create database... 0.466 seconds
    Populate database... 1.887 seconds
    Save database... 0.203 seconds
    Reload database... 0.087 seconds
    Search database... 1.873 seconds
    Sort database... 1.607 seconds
    Group database... 1.087 seconds
Score: 2982

JRMark (version 22.0.79): 2443

[madbrain]

The buffer i refered to is in the settings under Audio -> Audio Device -> Device settings.. - note that the dialog here is dependent on which audio output you have selected, and not all necessarily offer buffering settings, but most do.

Thanks. In the WASAPI driver, I increased the buffering to 500 ms, but the behavior is unchanged. I tried directsound as well, with most skip resistant setting, but also unchanged.
Strangely, right now, I can only play 7.1/192 kHz with Directsound - with WASAPI I'm getting a message that 192 kHz 8 ch 64 bit is not supported and I get downgraded to 2 ch. I could have sworn I was using WASAPI yesterday and 7.1 / 192 kHz. Not sure what other setting I might have changed.

Anyway, I looked at task manager more in detail also, with individual cores/logical processors. Most of the cores are active over time, but at low usage.

I observed the same thing when I tried Prime95 with a single worker thread. In either case, the CPU does not clock up. Looks like it clocks up only when the workload fills all the cores. Maybe this is just the way the power saver mode is designed, unfortunately.

FYI, I tried increasing the prebuffer to 20s. JRiver plays for 20s , then buffers for about 12 seconds, then plays again for another 20s, and so on.

I'm sorry I ruffled some feathers in this thread, I was only trying to find out the root cause - it sure is odd to see a CPU almost idle and have a process that's apparently compute bound not complete in time. But I guess that is just the way the OS/CPU power management feature has been implemented.

[madbrain]

it sure is odd to see a CPU almost idle and have a process that's apparently compute bound not complete in time. But I guess that is just the way the OS/CPU power management feature has been implemented.

Just for the heck of it, I just went into the machine's BIOS and disabled CPUs 3-8, leaving only 1-2 hardware threads.
I then tried my test case again, in the power saver profile. CPU went to 100% on both cores, and the CPU clocked up to 3.3 GHz in task manager.

Surprise : it plays for 20s, then buffers for only 1-2s , then plays again for 20s, and over. Ie. not quite there, but much better than with all 8 CPU cores/threads enabled, where it would play for 20s, then buffer for 12s.
You know there is something odd with power management logic when it causes better playback with a 2 thread CPU than an 8 thread CPU.

This is clearly an issue with the OS/CPU power management logic, just a very odd one.


However, in this case, switching to balanced or high performance profile doesn't help - there just aren't enough cycles for the computation. Ie. it still stutters with just the 2 CPU cores/threads.

[JimH]

Your benchmarks show a significant difference (and possible problem) with the power saver mode.  Not using it would be a reasonable solution.

Antivirus programs can also cause problems like this.  Media files should be excluded.

[madbrain]

Your benchmarks show a significant difference (and possible problem) with the power saver mode.  Not using it would be a reasonable solution.

Antivirus programs can also cause problems like this.  Media files should be excluded.

Agree - sorry for the trouble. Looks like I may just have to upgrade to a more efficient CPU to deal with the fan noise issue.