Print

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

[stricko]

I've started to get intermittent buffering when playing 6 channel audio from sacd iso or dff files. happens every 30 seconds or so. Not sure how long its been happening for, only noticed it in last couple of weeks.

setup is client/server, all w10 64 bit, wired gigabit. no recent hardware changes. client htpc is ssd only, plenty of space. 4gb amd x4 840. all software / drivers up to date.

any ideas how to start debugging this?

thanks

[Matt]

Well the drive or computer just isn't fast enough probably.

You could try increasing prebuffering in Options > Audio.  It might at least make the gap between drop outs longer.

[stricko]

Thanks for that

I tried the pre buffering thing a while back but it didn't seem to make much difference. I've been running some tests on a different htpc which didn't seem to have the problem..... until now. Same material, same server.

Audio played fine, apparently resampling from 352.8 kHz to 96 kHz, using Direct Sound.

Switched the audio device to wasapi, and I'm now getting "96 kHz 24bit (padded) 6ch using wasapi (not using enough bits to output the input directly)". But I get buffering as originally reported.

So I switch back to directsound. But now I'm getting buffering on that as well....

If it is something in the htpc not fast enough to cope, any suggestions on how I find out what....

[stricko]

Back to wasapi. I'm watching the task manager performance graphs of the server and client side by side. CPU is 37% on the server side, 56% on the client, memory 1.1 of 3gb on the server, 1.5 of 4gb on the client. Disk usage is barely registering.

No obvious spikes or dips when it decides to buffer......

No idea where to look next

[kr4]

Audio played fine, apparently resampling from 352.8 kHz to 96 kHz, using Direct Sound.

Try resampling from 352.8 kHz to 88.2kHz.   It eases the math load. 

[dtc]

Some tests to try. No one is definitive, but it might help narrow down the problem.

Copy the file to the client and play it directly rather than in client/server mode.

Connect the client directly to the file on the server, without going through MC on the server. (When you say client/server I am assuming you mean client/server with MC - also called Tremote.)

Do both of the above with and without Load Files to Memory at Start of Playback

If the file on the server is on a usb drive, move it to an internal drive on the server.

And, as Kal suggests, only resample in integer multiples.

[stricko]

Just had a couple of minutes to test. Copied sacd image to ssd on client and losded to local library. Same problem, so i guess that rules out network related problems.

Audio is being output over hdmi so im using the nvidia high def audio driver. From what i can see it doesnt support 88.2, and things got wierd when i tried to change to it.

Ill do more when i can

[Fitzcaraldo215]

That problem with NVidia has been around for a long time.  Apparently, it still does not support audio at 88 or 176k, unlike AMD or even Intel Integrated Graphics which do.  I find that somewhat surprising, but then their primary customers in the gamer market do not need those "audiophile" sampling rates.  NVidia and the others do handle hi rez at 96 or 192k, however.

I have not looked lately, but I never found anything in NVidia's online specs that made it clear exactly which audio sampling rates they did or did not support, a curious and downright unfriendly omission.  I have not forgiven them ever since.  I had to do some actual in-store testing to discover this limitation. Some may disagree, but I think conversion from DSD at integer multiple rates like 88/176k makes a small but worthwhile sonic difference.  And, as Kal says, it requires less PC resources.

[Hendrik]

And, as Kal says, it requires less PC resources.

Not going to argue about "audible differences" because thats a rabbit hole reserved for others - but this is just wrong. Any advanced resampler doesn't really care if its an "integer" or any other fraction - performance wise.

People bringing this argument often have a very naive and simple resampler in mind, but thats not how any of the things in MC work.

If you are having performance issues due to resampling (which would require a rather weak PC, fwiw), you can try to switch to the SoX resampler in the MC options, its quite a bit more efficient on performance.

[kr4]

Not going to argue about "audible differences" because thats a rabbit hole reserved for others - but this is just wrong. Any advanced resampler doesn't really care if its an "integer" or any other fraction - performance wise.

People bringing this argument often have a very naive and simple resampler in mind, but thats not how any of the things in MC work.

If you are having performance issues due to resampling (which would require a rather weak PC, fwiw), you can try to switch to the SoX resampler in the MC options, its quite a bit more efficient on performance.

I made this suggestion based entirely on experience with downsampling hi-rez multichannel files with MC. 

[stricko]

That problem with NVidia has been around for a long time.

Damn. And it's not that long simce I switched from AMD. I can't remember the details but there was some problem or other where AMD stopped supporting something I needed, so I changed.

More testing later now I've found the Sox option setting.

[stricko]

Okey dokey, we have a winner. Switching on the Sox resampling option fixed the problem. Initial track buffering time significantly reduced and not a trace of buffering during playback. Worked on both locally held iso file and over the network. Very impressive.

Does this result suggest that the original problem was CPU related? The Sox suggestion also caused me to read the pinned Sox thread which explained some of the earlier comments.

Many thanks

[Awesome Donkey]

Does this result suggest that the original problem was CPU related?

Very likely, yes.