Open dikonov opened 4 years ago
Note to self: it should be simple to insert a block of silence, but need to come up with a way of validating the implementation without having access to a physical DAC with such problem.
I can test it starting from today and until late April 2021. I was away and had no access to the hardware before.
IF the PCM bit-depth and frequency of the next stream is different from the previous stream: Option 1 - insert 0,5-1 sec of complete digital silence between such tracks. Option 2 - put the ALSA device to the default 'nothing is playing' state and re-init.
Added triage label to keep it visible. I'll see if I can add some code to do this, and provide you with something testable.
@dikonov I added a config option which specifies the amount of silence to add when the wave format changes. You will have to add it to the ~/.config/deadbeef/config manually, there's no UI.
streamer.format_change_silence X
X is the number of seconds of silence to add.
Please let me know whether this helps in any way.
You can grab the build from CI when it's ready: https://github.com/DeaDBeeF-Player/deadbeef/actions/runs/693363783
FYI: I didn't add anything like closing the device. I only added the code, which adds a buffer of 0 bytes which is approximately the specified duration ±100ms. This happens every time before playing the next track with new wave format.
If this is not enough - I would have to reconsider how to do the other thing you describe, although this may be quite hard.
I complied deadbeef with this patch and got a mixed result. I used the same record available as a regular CD (16-44 flac) and LP (24-96 flac) and an Arcam AVR receiver. It worked nicely with 0.5 and 1 second of silence while I had the software volume reduced to about 50% in deadbeef. The receiver produced some pops and indecent toilet sounds at stream boundaries but switched and played. There was 1 case of muting per 20+ good switches and it happened at tracks, where sound started immediately without any silent lead-in.
However, the problem returned as soon as I turned the volume up to 100%. The receiver resumed muting. The length of the silence block plays no role at high sound amplitudes. Perhaps, a quick 0,5 sec fade-out and fade-in might help, but I would not bet on it. I tried simulating volume fades manually without success. Anyway it would not work with DTS/TrueHD pass-through (desired for bluray audio streams ;) ).
A further remark. The DAC also reacts to sudden abrupt digital peaks in signal. E.g. it falls silent when playing an artificial track with isolated clicks and pops separated by digital zeroes (It was a negative of vinyl noise extracted during LP restoration). There is some form of protection against anomalous non-soundwave data on input.
I use an external multichannel receiver as a DAC to play audio from a PC running Linux-ALSA-deadbeef. The receiver is connected via HDMI to play 5.1 PCM data. This setup works well but there is a recurring problem. Different audio files use different sample rates and bit depth from 16-44 to 32-192 + mono/stereo/surround. When the PCM parameters change suddenly, the hardware of the DAC may get confused and lockup/mute the sound.
Steps to reproduce the problem
What's going on? Describe the problem in as much detail as possible.
The receiver stops playing. It mutes until you manually switch it to another audio source and back (this causes a complete reset of the internal DAC). Sometimes a single short abnormal click/noise may be heard. It appears that the hifi hardware treats the new track as if it had PCM parameters of the previous track, detects abnormal data and goes to an error state.
(!) Everything works correctly when there is a short pause (complete silence) between the same tracks.
PROPOSED ENHANCEMENT: Add an option to close audio device, insert a brief period of complete silence and reinit playing when the next audio track has a different PCM samplerate/bit depth/number of channels. This setting must override any gapless playback.
Information about the software:
Deadbeef version: All versions of Deadbeef cause the same problem. Affected victim software: Unknown firmwares of several Cambridge Audio and Arcam hifi receivers. Burr-Brown DAC chips inside.