Print

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

[Audio Only]

I am slightly under two seconds on my buffering -

Still get some skipping, hiccuping - it's like the the whole stream is chopped into smaller pieces.

When I set the the buffer to more than two seconds - I get the same error message

_________________________error message___________

Playback can not be started on the output "windows audio session API (WASAPI) using the format 96k hz, 24 bits sample 2 channel

Output format may not be supported by your hardware. You can use DSP studio to change the output to a compatible format. Also, make sure your system has a valid sound playback device and that it is properly configured in playback options.
__________________________________________________

Since everything works beautifully except when I increase the buffer sze, I believe the problem is not related to my hardware or configuration of the hardware.

At first I thought it was because I was using apple lossless, so converted them to wav files - still does it, maybe worse. Does it on some flac files.

Not consistent as to which songs it will do it on - at times will do it three or four times in an hour. Other times, 3 or four times in twenty songs.

Need to get some input to resolve this issue.

Thanks

Edited to add: when it starts skipping, simply have to stop the song, and restart, it will restart fine. Areal pain, though

[Vincent Kars]

Sounds familiar to me.
WASAPI seems to be pretty sensitive to buffersize.
The same will happen when using Foobar, increase the buffer and the audio starts to stutter.
An obvious one is to lower the buffersize, try 1 or 0.5

[Audio Only]

I'll give it a try down at 1, and if that doesn't work - I'll try lower.

The reason I was increasing the buffer was in an attempt to resolve the skipping issue.

But I'll take any number that works _grin_

[HiFiTubes]

What hardware?

[Audio Only]

Lynx two B sound card.

2.4 Quad core, 3 gig ram.

FWIW

I've tried changing buffer settings under _tools, options, Audio, _Audio Output, output mode - changing the buffer size as low as .25 seconds, and numerous increments up to 2.0 seconds at which point and above I get the afore mentioned error message, while at points below I get the "stuttering, skipping" effect.

Note: am going to go in under the _tools, options, Audio,_ "settings" tab and try changing the "prebuffering" from 6 seconds to 10 seconds.

Not sure how that "buffering" under the "setting" tab is different from "audio output" tab but it's worth giving it a try.

[Matt]

Reports from several users seem to indicate that Lynx cards can be problematic with WASAPI.

Perhaps you could try ASIO or Kernel Streaming?

[Matt]

I should add that I don't think any settings in Media Center will make much difference.  WASAPI is reliable, regardless of buffer sizes or other settings, when it works.

If it doesn't work, it's almost always a driver / hardware issue.  

There have been some reports of wireless network cards hogging resources when playing over wireless and causing sound cards to stutter.  I'm not sure if this would apply in your case.

[JimH]

There have been some reports of wireless network cards hogging resources when playing over wireless and causing sound cards to stutter. 

Here's one:
http://yabb.jriver.com/interact/index.php?topic=24031.msg398287#msg398287

[HiFiTubes]

What are your settings like for track changes, crossfade? gapless? Gapped? What about remove leading and trailing silence?

Try lowering all your buffers.

This could be a Lynx > WASAPI issue but would be great if there was a way MC could mitigate it, but from Matt has posted elsewhere, that may not be possible.

I haven't listened in a week due to some equipment changes, but my glitches seem to be minimized when I changed my track changes to Standard and unchecked remove leading and trailing. I'll do more listening next week.

[Matt]

What are your settings like for track changes, crossfade? gapless? Gapped? What about remove leading and trailing silence?

Like I said above, I don't think setting changes like this will make much difference.  I think there's an underlying driver or hardware issue that must be solved.

[HiFiTubes]

I saw that, but they did make a difference for me. I reported in the other thread with my other cheaper DAC the same issue arose with WASAPI.

This was over library server converting to mp3, and as soon as a changed from Smooth (normal) to Standard track changes the problem was gone.

You mentioned data shortfalls; I perceived a bit of irony in that less DSP (with Gapped creating silence between tracks) seemed to help in all cases. Whenever there was minimal buffering, even for a split second, on LS I would lose sync if I had some DSP involved which was trying, at the same sample rate, to tie together songs, at finish, using fades or smooth transitions at manual track changes.

[Matt]

I wrote to Lynx, offering to work with them on possible WASAPI issues.

If you're having problems with Lynx hardware, it might be helpful if you also wrote to Lynx to tell them seamless JRiver support is important to you.

Thanks.

[HiFiTubes]

I wrote to Lynx, offering to work with them on possible WASAPI issues.

If you're having problems with Lynx hardware, it might be helpful if you also wrote to Lynx to tell them seamless JRiver support is important to you.

Thanks.

I'll get in touch with Paul at Lynx when I get back, and summarize the 3? Lynx users' issues. I think I speak for all of us, thanks for dropping them a line. They have some WASAPI issues for sure; 192kHz isn't routed to the mixer properly at all.

[Audio Only]

"buffering" under the "setting" tab is different from "audio output" tab but it's worth giving it a try.

Increased buffering" under the "setting" tab from the recommended setting of 6 seconds to 10 seconds.
This setting has now given me over four hours of listening with no skipping or stuttering.
I have never before been able to get that much playing time without the problem - so hopefully that has resolved this particular issue.

Note: I am configured at 96k. I go digital out from the Lynx to a BSS FDS 366T digital crossover and am tri-amping using the output dacs ( 2x3 ) for dacs and go straight out analog from the output dacs to the amps - no preamps.

The BSS unit will accept a 96k input, but will not accept 192k.

[Matt]

I just wanted to follow-up to say I spoke with Paul at Lynx.  He was very helpful.

We've provided them software to test with, and they're providing us hardware to test with.  We'll let you know if we learn anything.

If you have recommended steps for reproducing the issues you've had, please let us know.

Thanks.

[HiFiTubes]

Great news, thanks Matt!! I'll do some testing when time permits.

[Matt]

We received a LynxTWO and have made some improvements.  Coming later this week in Media Center 15.0.94 (or newer):

Optimized: Reworked ASIO pipeline to improve buffer fill performance and remove any thread locking -- fill callback over 15% faster on a multi-core system, more on a single-core system.
Changed: Process memory cleanup performed when switching views or minimizing the program could cause a playback hiccup with some audio hardware (cleanup no longer done while playing).

I think the changes above will help our Lynx users.

We haven't spent any time with WASAPI (yet?), as both Lynx and JRiver recommend ASIO.  

Also, we have requested to Lynx to consider adding support for ASIO buffers sizes larger than 1024 (assuming the hardware can support it).  As the sample rate goes higher, the buffer duration shrinks.  This is why your tests of 192 KHz material showed more problems.

[HiFiTubes]

Thanks Matt, great news, thanks for all your hard work.

I have had really good luck with WASAPI on my client whereas Lynx ASIO just gots bogged down and creates high system latency, but I'll check it out again.

Maybe this will lead to Lynx updating their driver?

[Audio Only]

Ummm, while I realize that certain segments believe "bits are bits & bytes are bites" it has been my observation ( and that of others ) that certain aspects affect sound and there is audible differences in some systems.

while I did my comparisons initially, and have not done any after my full configuration - Wasapi _sounds_ better than ASIO in my system.

When I get some time I will have some friends over and do some more comparisons.

You did ask for feedback - so this is the feedback I have - if after doing careful comparison with other listeners confirming (blind) I have further input - that ASIO sounds better or they sound the same, or similar - I will post on that also - but will be a while before I can get a listening session setup with the usual suspects.

[Matt]

Please let us know if you are still having issues with Lynx hardware using the latest build.

These two changes in build 94 (or newer) should have helped:
Optimized: Reworked ASIO pipeline to improve buffer fill performance and remove any thread locking -- fill callback over 15% faster on a multi-core system, more on a single-core system.
Changed: Process memory cleanup performed when switching views or minimizing the program could cause a playback hiccup with some audio hardware (cleanup no longer done while playing).

Thanks.

[HiFiTubes]

I testing now.

I do still have the glitches when using WASAPI.

My older/other posts show system latency is much higher using Lynx ASIO with a network source; creeps higher and higher going from 96>192kHz.

Matt, wondering if this whole latency issue is because my low power system is being forced to doing decoding on it, being the client. I still can't get decoding done on the server when setting Always Convert>Uncompressed.

WASAPI is incredible low (green) for 192kHz material, whereas Lynx ASIO is in the red for the same network-served material.

[HiFiTubes]

Please let us know if you are still having issues with Lynx hardware using the latest build.

These two changes in build 94 (or newer) should have helped:
Optimized: Reworked ASIO pipeline to improve buffer fill performance and remove any thread locking -- fill callback over 15% faster on a multi-core system, more on a single-core system.
Changed: Process memory cleanup performed when switching views or minimizing the program could cause a playback hiccup with some audio hardware (cleanup no longer done while playing).

Thanks.

Using WASAPI is pretty bad right now. ASIO doesn't result in the sync loss, but I did hear some noise on track changes from the kitchen last night. I'll have to double-check tonight.

Would a fair test of WASAPI be if I were to load some files into Foobar and use their WASAPI plugin? I have tried all kinds of DSP settings in MC to no avail (2 second gap, 1 second aggressive crossfade, etc.).

And if you get a sec, could you please post if I should be having no problem setting my server to Always Convert>Uncompressed? It doesn't work for any file type, and every time reports a file location error.

[Matt]

Using WASAPI is pretty bad right now. ASIO doesn't result in the sync loss, but I did hear some noise on track changes from the kitchen last night. I'll have to double-check tonight.

ASIO is recommended.  Please double-check that the 'Use large hardware buffers' option is enabled in Media Center.  The Lynx control panel should show "1024" for the buffer size during playback.

Would a fair test of WASAPI be if I were to load some files into Foobar and use their WASAPI plugin? I have tried all kinds of DSP settings in MC to no avail (2 second gap, 1 second aggressive crossfade, etc.).

If you play identical sources, like the same file sitting on the local computer, it would be an interesting test.  If Media Center is streaming and Foobar isn't, or one is resampling and one isn't, it wouldn't be a good test.

[HiFiTubes]

Lynx also has that "use double buffer" option which I have enabled. Isn't there a DSP option to enable if you hear noise on startup? I'll verify everything is setup okay tonight.

I'll test with Foobar and make an identical playlist, same disk location, etc.

ASIO is recommended.  Please double-check that the 'Use large hardware buffers' option is enabled in Media Center.  The Lynx control panel should show "1024" for the buffer size during playback.


If you play identical sources, like the same file sitting on the local computer, it would be an interesting test.  If Media Center is streaming and Foobar isn't, or one is resampling and one isn't, it wouldn't be a good test.

[HiFiTubes]

Made a lot of progress tonight. Hope this helps.

I setup Foobar to use WASAPI for 'Lynx Speakers' and set up the resampler to ultra @ 96kHz. I had no problems. Then I then added the crossfade DSP and a 'remove silence' plug. These are all stock plugins.

It turns out that the crossfade didn't work at all, so I removed it. But what I found was the remove silence feature started causing the sync drop issue in Foobar. I could reproduce it on demand using some tracks I will look at in a .wav editor once I decode from flac.

So I went into MC and had no problems. But then I changed the crossfade in MC to match Foobar by setting to gapped payback, left 'remove silence' enabled, and the exact same problem cropped up.

Now I get this sync problem when NOT using a gapped track setup, so it seems to be related to the 'remove silence' option as applied to WASAPI, and it somehow creeps in, overall much less than this gapped setup, with my setting of crossfade agressive 1 second.

[HiFiTubes]

Finally, neither DS or ASIO exhibit this behavior (sync loss/garbled playback) when using standard gapped playback (1-2 seconds tested) in conjunction w/ remove silence, just WASAPI.

[HiFiTubes]

Got another interesting one here; possible related to all this.

My EMU 0202 doesn't work with WASAPI when I try to stop playback; starting playback is no problem. It locks up MC and basically my PC. I have updated firmware on the 0202 and MC, and ASIO works without a hitch.

I just changed to "on Stop: fadeout slow" and no change. Have to reboot now to test some other settings, including if I can reproduce the sync loss issue with this DAC.

MC process simply can not be stopped and I have to reboot; even if I kill the EMU control panel and power down the 0202.

[Matt]

MC process simply can not be stopped and I have to reboot; even if I kill the EMU control panel and power down the 0202.

Could you email me a log showing this problem?

Thanks.

[Matt]

Made a lot of progress tonight. Hope this helps.

I setup Foobar to use WASAPI for 'Lynx Speakers' and set up the resampler to ultra @ 96kHz. I had no problems. Then I then added the crossfade DSP and a 'remove silence' plug. These are all stock plugins.

It turns out that the crossfade didn't work at all, so I removed it. But what I found was the remove silence feature started causing the sync drop issue in Foobar. I could reproduce it on demand using some tracks I will look at in a .wav editor once I decode from flac.

So I went into MC and had no problems. But then I changed the crossfade in MC to match Foobar by setting to gapped payback, left 'remove silence' enabled, and the exact same problem cropped up.

Now I get this sync problem when NOT using a gapped track setup, so it seems to be related to the 'remove silence' option as applied to WASAPI, and it somehow creeps in, overall much less than this gapped setup, with my setting of crossfade agressive 1 second.

It sounds like both Foobar and JRiver show the same problem with WASAPI.  I can't explain it, but since it doesn't happen with Directsound or ASIO, and happens with other programs, it doesn't point to a core audio engine issue.

Like I said above, ASIO is recommended for the Lynx card.  And since you mentioned it doesn't have this problem, isn't that the way to go?

[HiFiTubes]

Didn't see your posts until now Matt.

Well, ASIO is okay, but I do see more system latency at my 96kHz setting for all playback, which goes really high with 192kHz. WASAPI is just inredibly low and to me actually does sound "cleaner" (I know I know).

Anyway, I'll try to get you a log Tuesday for the 0202 issue. thanks.

[Audio Only]

. WASAPI.... actually does sound "cleaner".

+1