Print

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

[HiFiTubes]

I have been observing a problem on two different PCs with two different external DACs when using WASAPI. Both use LS, one over LAN and one over WAN. his problem is over WAN, but the same loss of sync problem occurs on either system at different times, always on track changes, but the bug can be manually reproduced by Seeking.

WASAPI - Seek to the middle of any high quality mp3 song, hear a tiny static sound then silence while MC buffers for 4 seconds, then playback resumes out of sync, every single time.

DirectSound - Seek to the middle of a any other high quality mp3 song using , hear no static sound then silence while MC buffers, then playback resumes perfectly, always.

I have observed a similar sync problem on my other system using WASAPI, and the problem is that this sync issue with WASAPI crops up on track changes during casual listening. One system is doing high-quality mp3 of WAN, the other is doing no transcoding over LAN.

At work over WAN:

Prebuffering - tried up to 20 seconds w/ no change
Buffer - tried .25 to 1 second w/ no change

Work PC doing hq mp3 over WAN specs:

JRMark (version 15.0.80): 1533

Media Center 15.0.80 Registered -- C:\Program Files\J River\Media Center 15\

Microsoft Windows Vista 6.0 Service Pack 2 (Build 6002)
Intel Pentium III 2989 MHz MMX / Memory: Total - 3404 MB, Free - 1191 MB

Internet Explorer: 7.0.6002.18005 / ComCtl32.dll: 5.82.6001 / Shlwapi.dll: 6.0.6002 / Shell32.dll: 6.0.6002 / wnaspi32.dll: N/A
Ripping /   Drive E:   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive G:   Mode:ModeSecure  Type:Auto  Speed:Max
  Drive J:   Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No  

Burning /  Drive E: Optiarc  DVD+-RW AD-7200S   Addr: 0:2:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Drive J: LITE-ON  DVDRW SHM-165P6S   Addr: 1:0:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: No /  Write CD-Text: Yes
  Use playback settings: Yes /

Portable Device Info
  Removed devices: Multi Flash Reader (I:),Generic STORAGE DEVICE (F:),F:\


Interface Plugins:
  last.fm (Active)
  TiVo Server (Active)
  Playing Now

[JimH]

Try the "Weird Problems" thread in my signature.  A driver for a network card would be my first thought, but there are other possibilities.

[HiFiTubes]

Try the "Weird Problems" thread in my signature.  A driver for a network card would be my first thought, but there are other possibilities.

Okay, but WASAPI is so dependent on network driver cards, how is it the most reliable best sounding method of playback?

Again, two different systems that work with DirectSound so it's not the server, but on the client end, and not sure how the network drive is going to fix WASAPI while it does not adversly affect DirectSound.

As I have posted elsewhere the system latency is high with even ASIO whereas WASAPI and DirectSound cprovide low system latency even when streaming 192kHz files on the network.

This problem is with low bandwidth mp3 so I'm at a loss for now. Will keep poking I guess.

Or maybe just use Directsound.

[HiFiTubes]

Kernel and WASAPI act the same except some minor skips on start up with Kernel.

WASAPI (drops sync) - Seek to the middle of any high quality mp3 song, hear a tiny static sound then silence while MC buffers for 4 seconds, then playback resumes out of sync, every single time playback continues skipping.

Kernel Streaming (drops sync) - Seek to the middle of any high quality mp3 song, hear a tiny static sound then silence while MC buffers for 4 seconds, then playback resumes out of sync, every single time playback continues skipping.

DirectSound (perfect)- Seek to the middle of a any other high quality mp3 song using , hear no static sound then silence while MC buffers, then playback resumes perfectly, always.

Wave output (perfect)- Seek to the middle of a any other high quality mp3 song using , hear no static sound then silence while MC buffers, then playback resumes perfectly, always.

ASIO4All (perfect)- Seek to the middle of a any other high quality mp3 song using , hear no static sound then silence while MC buffers, then playback resumes perfectly, always.

[Matt]

What sound cards are you trying?

What seek mode (smooth, standard, etc.) are you using?

Different sound card drivers handle data shortfalls differently.  Some loop, others play and stop, and maybe others may get unhappy?

I'm testing by intentionally slowing down the source to force differing amounts of buffering.  I haven't been able to reproduce yet.

[Matt]

ASIO4All (perfect)- Seek to the middle of a any other high quality mp3 song using , hear no static sound then silence while MC buffers, then playback resumes perfectly, always.

Our ASIO implementation writes silence on data shortfalls.  This explains why it works better with your hardware.

With other implementations, like WASAPI, it's up to the driver and hardware to handle shortfalls.  It sounds like your hardware does not handle shortfalls well.  The hardware I have here does handle shortfalls gracefully.

Because of this, I would recommend using ASIO in your case.  Using a native ASIO driver is better than using ASIO4All, since ASIO4All adds another layer of abstraction and complexity.

[HiFiTubes]

It was set to Smooth (Normal) not Standard. I don't remember changing that; does it inherit from the server?

Changing to Standard fixes the problem! But I wonder if the fact that this problem was also cropping up during track changes, and the perceived recent improvement when I switched to Smooth crossfades of 1 second, means anything. Are they related? The crossfade is tricking the hardware drive etc. and causing loss of sync?

Could you recommend a buffer setting if we want a 1 second smooth crossfade? Do we have to have the buffer set to at least 1 second or can we leave it at .5? Am I taxing the system if I set an Agressive crossfade of .3 seconds?

I know I have observed the sync drop much less since changing to smooth from aggressive.

thanks

[Matt]

It sounds like you have a really simple problem.  There's probably no need to be thinking so hard about settings, buffering, network drivers, etc.

Your sound hardware can not handle a data shortfall in the playback state.  It loses sync and buffer alignment when there is a data shortfall. 

If you are playing over wifi, occasional data shortfalls are a fact of life.  You can mitigate them, but not eliminate them.

The best solution, in my opinion, is to use ASIO.  It writes silence on a buffer shortfall, which will solve your problem.

[HiFiTubes]

The Lynx system gets this problem on a gigabit LAN. Expensive gear so it's a pretty frustrating issue to spend some coin and deal with such a simple problem.

I wasn't using ASIO because system latency was high with LServer over LAN and I was getting that maximize/minimize glitch most likely due to (higher system latency when using ASIO). When I switched to WASAPI I had no min/max glitch and latency was in the green.

Maybe the Lynx x64 driver not sure.

I'll play around with it some more soon on the more important, better sounding, and more complicated system.

[Matt]

Does anyone else have hardware that switches to garbled output with WASAPI after a buffer shortfall?  If so, what is the hardware?

It would probably be possible to add a WASAPI option to write silence on shortfall.  However, I would like to see the problem first hand before adding complexity to the code to accommodate drivers that can't handle a shortfall.

[HiFiTubes]

Does anyone else have hardware that switches to garbled output with WASAPI after a buffer shortfall?  If so, what is the hardware?

It would probably be possible to add a WASAPI option to write silence on shortfall.  However, I would like to see the problem first hand before adding complexity to the code to accommodate drivers that can't handle a shortfall.

I had a really hard time, but was able to reproduce it once after about an hour of listening, and doing track changes. Cross-fade aggressive at 1 second (pre-buffer 4) has seemed to really lessen the occurrence of this so I'm hopeful.

This Interact member seems to have the same problem, (HiFace using WASAPI).

At home, I am using a Lynx AES16-E card feeding a Zodiac+ DAC on Windows 7 x64.

Matt, the reason, in my confessed ignorance, that I start tweaking buffers is because when there is a data shortfall I thought the buffer was supposed to prevent any loss of sync or playback error from getting into downstream in the signal chain.

[HiFiTubes]

It gets stranger.

I created a new zone with the intent of having a dedicated one that does no upsampling and allows the Lynx to auto-change sample rates, and the external DAC then locks to the Lynx to get the bitstreamed digital audio data and embedded word clock. I also decided that since a bunch of 'philes were coming this weekend, I would change to Gapped 2 Second playback to mimic a CD player and give time between each track change (also given my recent issues with crossfading, thought this would be safer). Same gear, same WASAPI output, just these DSP changes.

So, first tracks buffers maybe 2 seconds on startup of playback, then every single track change results in the same sync loss. Maybe this Antelope DAC is up to snuff? I have no idea. The Lynx AES16E driver?

Not sure how a 2 second pause can result in a data shortfall. Is the 2 second pause by nature a data shortfall?

I'm lost as to how the elegant and well-designed buffers in MC seem to offer no protection when using this particular (highly regarded gear).

[Matt]

Is the 2 second pause by nature a data shortfall?

No, it will play two seconds of silence.  To the output plugin talking to the soundcard, this silence looks the same as any other data.

Is it possible you're hardware drops sync on silence?  Use Media Editor to crop some sections out of a WAV file.  Then play it and see if it drops sync every silent section.  Or use internal volume and mute and unmute during playback.

[HiFiTubes]

Thanks Matt. I unticked the Remove leading/trailing silence and it playsback okay now. Some DACs do auto-mute with no output feeding in to them.

Since I'm doing native sample rates I enabled the hardware sync silence option at 1/2 too. Either way, every now and then, maybe twice in an hour with none of the aformentipned errors I would get pure static.

Seems like my hardware gets confused when I start adding DSP stuff like crossfades and smooth seeks. I'm pretty happy with this native sample rate setup; the DAC has time to sync on sample rate changes w/o too much delay. I tested switching between 44, 88, and 96kHz.

[HiFiTubes]

I also wanted to express my thanks and that it seems from what you describe that this may be somewhat out of your hands. I'll ping the guys at Lynx regarding how WASAPI works with their card on x64.

[Coolhighend]

I experienced exactly the same behavior with my setup (Win7 32bit, LynxAES16, Intel D945GSEJT Atom Mobo, Berkeley Alpha Dac). I was tweaking for a long time and the only thing that helped (the out of sync problem has not completely gone, but it almost does not happen any more) was a change in the computer bios. The D945GSEJT lets you switch off the Multithreading in the bios, thats what I did. This helped a lot in my case.

[HiFiTubes]

Interesting. I'm at a similar point. I had a listening session Saturday for about 4 hours with no problems.

I think I was using the native sample rate zone I made so the Lynx was auto-switching and I didn't have any issues.

I have observed some static or loss of sync when using crossfading, albeit rarely, and I will be testing using a fixed sample rate with both crossfading vs. gapped (since I'm adding a word clock to sync ADC>Lynx<DAC which means not more auto-change of sample rate).

Do you ever get static or white noise? Or just loss of sync?

[Coolhighend]

I got static noise in some cases, out of sync in most cases. I still can trigger it using a playlist with a mix of 16/44, 24/96 and 24/192. Skipping trough the playlist and forcing the hardware to change bit & sample rates every few seconds will show the problem.

With multithreading on, I will run into out if sync after af few skips. With multithreading off, I will be able to skip about 10 times more until the out of sync happens. That means in practice that it is no more a real problem under normal listening conditions.

There is another interesting beavior of MC. With multithreading off, the program needs some time for buffering when switching bit/sample rates, 1 or 2 seconds or so. However, with mulithreading on, I can't see in all cases that MC is buffering. Sometimes it starts playing immediately and thats usually the moment where the problem occurs. I assume that the hardware is not yet ready at that moment.

[HiFiTubes]

I just caused the sync loss when choosing a "Play" from a Tile during playback. 3rd song I played after getting home.

Using fixed sample rate and I don't see any buffering in MC, but all the initial experiences cropped up when buffering was involved.

You are using 32bit and I'm on 64bit but we both have Lynx cards. Do you have a PCI or PCI-E version?

[Coolhighend]

I use the PCI version.

[raym]

Does anyone else have hardware that switches to garbled output with WASAPI after a buffer shortfall?  If so, what is the hardware?

I just found this thread as I've experienced garbled audio from time to time using an external USB soundcard with WASAPI and MC. Really difficult to reproduce the problem but when it happens, you can definately hear it. Pausing for a short while and then resuming sorts it out.

Will the issue be fixed or do I need to mess with the buffer timing settings in MC for now?

[HiFiTubes]

I just found this thread as I've experienced garbled audio from time to time using an external USB soundcard with WASAPI and MC. Really difficult to reproduce the problem but when it happens, you can definately hear it. Pausing for a short while and then resuming sorts it out.

Will the issue be fixed or do I need to mess with the buffer timing settings in MC for now?

Sounds like we all have the same problem. I call it a loss of sync, and pause and resume seems to fix the problem. I had this issue on my usb dacs: zodiac+ and my much cheaper Maverick D1.

I'm not sure it was my Lynx card given the problem cropping up on each DAC, but I will be listening more as I just got my replacement Zodiac DAC back in my system today.