SPDIF on Windows
Lots of problems have been reported on windows. Often this is accompanied by "audio output is late/starving" errors.
One user says: VLC doesn't change the samplerate and tries to output 48khz while the device is still in 44.1khz. This can indeed be the problem, since VLCs SPDIF resampler is a dummy resampler, that cannot handle resampling properly. (The OSX audio output recently ran into the same issue)
Activity
changed milestone to %0.8.5-test3
changed milestone to %Bugs paradize
http://forum.videolan.org/viewtopic.php?t=15024
""when I change the Audio output module option to (Win32 waveOut extension output) I receive no error messages. The Dolby Digital signal is sent properly to my Yamaha receiver, the receiver's status indicators show it is a Dolby Digital signal, and the audio output is fine and distortion free. ""
I hear some SPDIF audio distorsion even with audio output module set to "Win32 waveOut extension". But far less distorsion than SPDIF with "Default" audio output.
The distorsion was hard to hear on some movie soundtracks, but with a test DVD with clean signals such as sine waves and white noise I could clearly hear some stuttering; a few short drops every second.
This is on a system that plays SPDIF audio just fine with other software.
So I'd like to ask 'tonsofpcs' who comments above: Are you sure your SPDIF audio output truly is "fine and distortion free"? Is this after critical listening to well chosen revealing content?
Original author: WinTakeAll
assigned to @atmo
May research on this point leads to some major changes int waveout.c - because I found at two things which can lead to trouble with spdif passthrough:
-
first point the feeding thread starts exactly one buffer playtime after output create, but this is wrong, it should start than when the first call to play() is done - so it is currently allways to early, and gets no audio buffers from a_out, -- solution start sequence used from alsa.c - so output starts and right time (in sync)
-
next one - the Output is synchronized on the driver callback (Wave..) - for normal output via kmixer driver (Stereo, Mono) it works reliable, but on passthrough I have seen, that this callbacks are not in sync with real output - so the call makes us believeing that are 5 blocks are played, but in real only 4,8 or so are played - this leads to wrong calcuation of next_time in the waveout thread, which is based on buffercount * buffer_play_time ... this accumulates with the terrible precision of gettickcount to going out of sync.
--> solution for me: modified waveout.c to have two different thread functions, one is used for normal Stereo/mono playback (current implementation). In case of SPDIF passthrough I launch another thread, which doesn't use the callback from the driver to synchronize/ feed output -- and uses the logic from oss.c (waiting, and, feeding...)
--> if it still occurs that a "buffer underun" happens, I just replay up to three times the same audio frame (configurable) - so there are no klicks hearable... also for SPDIF (for me)
-
For most users it should work now better so far - what I changed?
- improved synchronization between the arriving data in the aout queue -- with the real windows output.
But its still borderline - for me it happens on a dual core that the audio queue (down from decoder, mixer and so on) gets empty - and it takes much too long until the next audio buffer arrives - but only if I have opened a secondary CPU consuming application like VNC Viewer.) This issue stills needs investigation - but has nothing to do with the SPDIF problems itself.
added Status::fixed label
