I'm having a problem with music playback in Foobar when using the WASAPI plugin.
If I'm using WASAPI (event), then when I select a track of a different bitrate to the playing track, playback doesn't start at the beginning - it starts around 5 or 10 seconds into the track. This is independent of whether I had stopped the previously playing track first.
It only happens when the bitrate of the tracks changes, i.e. if I select another 16bit/44000 Hz track it doesn't happen, but if I then select a 24bit/96000Hz track it does.
Interestingly, when I use the WASAPI (push) setting, it only happens when I am going UP in bitrate, i.e. selecting a higher bitrate track after playing a lower bitrate tracks. It does not happen the other way round.
All my music is in FLAC format. Any help appreciated!!
It would help if you could tell us your exact configuration (soundcard model, soundcard driver version, Windows version, WASAPI plug-in version).
Certainly sir -
Soundcard: none
Windows: Windows 7 Ultimate SP1
WASAPI plug-in version: 3.1 (the latest as far as I understand)
Output in Foobar is listed as "WASAPI (push) : Speakers (Weiss Firewire IO Audio)". When setting up the DAC I had to install some firewire driver thing also.
There is no soundcard as audio is sent digitally via a firewire card (VIA card) to an external DAC (Weiss DAC2). The DAC2 is set to auto-sample rate switching ("Allow WDM to change sample rate").
Thanks
Thanks for the report. I'll see what I can do about it, though it looks like a device-specific problem. One solution would be to resample everything to the same sample rate to prevent device reinitialization which seems to be problematic.
I'm still getting issues with this. Am I the only one? Would really appreciate some help with it!
Your DAC switches clock between 44.1 and 48 (multiples). It takes some time.
If you use DirectSound, Windows does re-sample everything to multiples of 48kHz, that's why you don't hear that pause. Maybe you want to use a resampler in the chain - I use the SoX based one for my E-MU card (that has the same setup of two separated clocks).
Your DAC switches clock between 44.1 and 48 (multiples). It takes some time.
If you use DirectSound, Windows does re-sample everything to multiples of 48kHz, that's why you don't hear that pause. Maybe you want to use a resampler in the chain - I use the SoX based one for my E-MU card (that has the same setup of two separated clocks).
I don't think it's the DAC time, as when the track starts playing it's further forward than the time spent waiting!
I am having a similar problem with the wasapi (Push or Event) plugin. The problem exists over the HDMI (Intel HD Audio) connection, optical (Realtek HD)playback is fine.
When I select a FLAC track, the track begins playing however the audio doesn't kick in for approximately 1.5 seconds. If I switch tracks manually either of the same bitrate/Sampling or a different one, same thing, no audio for 1.5 seconds.
Alternatively, if I create a playlist of varying bitrate/sampling, the first track manually selected behaves same as above. Yet, if I then leave the playlist to play through each track in order, there is no audio problem.
I have played around with the delay buffer settings to no avail. I would gladly use the optical output and avoid this mess altogether, but I use the HDMI connection for DTS-HD Master Audio.
I have a onkyo tx NR-609 and onkyo HT R-391 and have tried the HDMI connection to my Samsung 27inch monitor as well.
The front display on both Onkyo AVR's re-initializes when the described problem happens. And I therefore see this as the plugin telling the AVR something incorrectly, resulting in the re-initialization. (As If I'm switching between listening mode or even inputs).
I have not used any previous Wasapi versions as I have just recently moved into FLAC /lossless audio, previously being an iTunes user
Thanks!
Windows 7 SP1 64bit Professional
Gigabyte z77-up5th
i7-3770K
32GB DDR 1600 Ram
Intel HD Audio Driver (Current)
Wasapi 3.2.3
Have you tried foo_dsp_pregap to see if you can initialize your receiver silently?
Isn't this inherent to the way many digital a/v connections operate? (and thus outside the capabilities of Foobar2000 to solve?)
As far as my understanding of the HDMI protocol goes it operates a little like this: When opening a stream the source negotiates with the destination device to determine it's capabilities and to set the samplerate/bit-depth that will be used. This is done before any actual audio/video data is transmitted. Every time the source format changes the stream has to be stopped and started again to negotiate a new setting for the stream. This might be the case for this firewire connection too..
This renegotiating (and/or clock setting change in the destination device) could be causing the silence you're talking about.
A simple solution has already been given by Peter: resample to the same rate/depth
edit: found a forumpost talking about the same issue, pointing to the possibility it's due to the DAC and the fact it's buffered: http://forums.naimaudio.com/topic/buffered...switching-issue (http://forums.naimaudio.com/topic/buffered-dac-and-sampling-rate-switching-issue)
Thanks for quick replies everyone!
Sandrine- The DSP pregap has reduced the silence by approximately 1250ms, even if I configure the pregap to create a 1250-4000ms the slight gap remains. Could this be the Onkyo's DAC limitations?
Propheticus- I'm just now reading into the suggested post, thanks! My issue is not bitrate/sampling dependent though, it is manual track selection dependent. Resampling unfortunately fixes nothing for me. If I select a 16bit 44.1KHz track I see the AVR re-initialize, if I then jump manually to another 16bit/44.1KHz track same thing, further, a 24bit 96Khz track with the produce the same silence/reinitialization even with the above mentioned DSP pregap. Argh. lol.
I can't thank you guys enough for the quick and precise assistance!
You could try preventing the stopping and starting of the stream between tracks by using a crossfader. By default most don't crossfade on manual change, but can be set to do so.
I'll definitely try the crossfade tomorrow. I spent most of the afternoon setting up plex HT and have discovered that the problem does not exist, using the built in wasapi event. No re-initialization on same/varying sampling/bitrate, no problem, weird.