Issues with DACs on Linux

[peppy.player]

Hi,

I use VLC 3.0.12 on Raspberry Pi 4 runnning Raspberry Lite OS 32-bit. I connect DACs to Pi over USB. So far I tested 3 different DACs and two players: VLC and MPV.
- Alien DAC (PCM2702) doesn't have any issues with VLC and MPV players.
- Topping E30 and Khadas Tone Board DAC have issues (no audio output) with VLC when I skip to different time in audio tracks or switch to another track. Both DACs don't have that issue with MPV player.

Sometimes VLC recovers itself when new track starts playing automatically or I manually switch to another track. I use the following command line parameters:
--aout=alsa --alsa-audio-device=default --audio-resampler=disable --no-audio-time-stretch --verbose=2 --file-logging --logfile=/home/pi/vlc-log.txt

I see in the release notes that in VLC 3.0.16 the similar issue was fixed 'Fixes dropping audio on seek with specific MP4 content':
https://www.videolan.org/vlc/releases/3.0.16.html
Just wondering if that's the same issue.

Just in case here is the log file when audio drops after skipping to another time in the audio track:

Code: Select all

flac debug: emulated sync word flac debug: emulated sync word main debug: Buffering 0% main debug: Buffering 2% main debug: Buffering 4% main debug: Buffering 6% main debug: Buffering 9% main debug: Buffering 11% main debug: Buffering 13% main debug: Buffering 15% main debug: Buffering 18% main debug: Buffering 20% main debug: Buffering 22% main debug: Buffering 25% main debug: Buffering 27% main debug: Buffering 29% main debug: Buffering 31% main debug: Buffering 34% main debug: Buffering 36% main debug: Buffering 38% main debug: Buffering 41% main debug: Buffering 43% main debug: Buffering 45% main debug: Buffering 47% main debug: Buffering 50% main debug: Buffering 52% main debug: Buffering 54% main debug: Buffering 57% main debug: Buffering 59% main debug: Buffering 61% main debug: Buffering 63% main debug: Buffering 66% main debug: Buffering 68% main debug: Buffering 70% main debug: Buffering 73% main debug: Buffering 75% main debug: Buffering 77% main debug: Buffering 79% main debug: end of audio preroll main debug: Buffering 82% main debug: Buffering 84% main debug: Buffering 86% main debug: Buffering 89% main debug: Buffering 91% main debug: Buffering 93% main debug: Buffering 95% main debug: Buffering 98% main debug: Stream buffering done (4086 ms in 29 ms) main debug: Decoder wait done in 0 ms main warning: playback too early (-96174): down-sampling main warning: playback too late (110306): up-sampling main warning: playback way too late (203080): flushing buffers main debug: inserting 51591 zeroes main warning: playback too late (72377): up-sampling main warning: timing screwed (drift: 165441 us): stopping resampling main warning: playback way too late (258300): flushing buffers main debug: inserting 51972 zeroes main warning: playback too late (80854): up-sampling main warning: timing screwed (drift: 173984 us): stopping resampling main warning: playback way too late (270229): flushing buffers main debug: inserting 51454 zeroes main warning: playback too late (72708): up-sampling main warning: timing screwed (drift: 163608 us): stopping resampling main warning: playback way too late (260490): flushing buffers main debug: inserting 51393 zeroes main warning: playback too late (70476): up-sampling main warning: timing screwed (drift: 162990 us): stopping resampling main warning: playback way too late (257217): flushing buffers main debug: inserting 51775 zeroes main warning: playback too late (78053): up-sampling main warning: timing screwed (drift: 173214 us): stopping resampling main warning: playback way too late (264664): flushing buffers .....

The last messages repeated over and over again until the playback resumes to normal when I manually switch the audio track.
Has anybody seen the same issue and knows how to fix it?

Thank you!

[Rémi Denis-Courmont]

It seems that the device driver fails to provide stable enough timestamps.

[peppy.player]

Why different DACs work differently? One works without issues with VLC and another with issues. Doesn't VLC use the same device driver for both DACs? Thanks!

[peppy.player]

Why are there up/down sampling messages in the log when I use the following parameters when I start VLC?
--audio-resampler=disable --no-audio-time-stretch

[Rémi Denis-Courmont]

You said that they behaved differently, so it's a little strange to then ask if they behave differently...

You're better placed to answer those questions than people here who don't have access to your pieces of hardware.

[peppy.player]

I use VLC as a default player and it would be great to fix the issue.
You mentioned that 'the device driver fails to provide stable enough timestamps'. Is that driver the part of the OS or the part of the VLC?
Here is the output from the command 'cat /proc/asound/card2/stream0' for the DAC which has issues with VLC:

Code: Select all

Topping E30 at usb-0000:01:00.0-1.1, high speed : USB Audio Playback: Status: Running Interface = 1 Altset = 1 Packet Size = 72 Momentary freq = 44105 Hz (0x5.8360) Feedback Format = 16.16 Interface 1 Altset 1 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 32 Channel map: FL FR Interface 1 Altset 2 Format: S32_LE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 24 Channel map: FL FR Interface 1 Altset 3 Format: SPECIAL DSD_U32_BE Channels: 2 Endpoint: 1 OUT (ASYNC) Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000, 705600, 768000 Data packet interval: 125 us Bits: 32 DSD raw: DOP=0, bitrev=0 Channel map: FL FR

Here is the output from the same command for the DAC which doesn't have issues with VLC:

Code: Select all

Burr-Brown Japan Burr-Brown Japan PCM2702 at usb-0000:01:00.0-1.1, full speed : USB Audio Playback: Status: Running Interface = 1 Altset = 1 Packet Size = 192 Momentary freq = 44100 Hz (0x2c.199a) Interface 1 Altset 1 Format: S16_LE Channels: 2 Endpoint: 2 OUT (ADAPTIVE) Rates: 32000, 44100, 48000 Bits: 16 Channel map: FL FR Interface 1 Altset 2 Format: S16_LE Channels: 1 Endpoint: 2 OUT (ADAPTIVE) Rates: 32000, 44100, 48000 Bits: 16 Channel map: MONO

Please let me know if you need any additional info from my side.

[Rémi Denis-Courmont]

Again, I can't answer that question. You have the hardware to make measurements; I don't.

[peppy.player]

I've found that everything works fine when PulseAudio is in use for example in the 'Raspberry Pi OS with desktop and recommended software'. In this case the content of the /proc/asound files is like this:
/proc/asound/card2/pcm0p/sub0/sw_params:

Code: Select all

tstamp_mode: ENABLE period_step: 1 avail_min: 661 start_threshold: 4294967295 stop_threshold: 1386217472 silence_threshold: 0 silence_size: 0 boundary: 1386217472

/proc/asound/card2/pcm0p/sub0/hw_params:

Code: Select all

access: MMAP_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 661 buffer_size: 2644

If I remove PulseAudio or use the OS without PulseAudio e.g. Raspberry OS Lite then the issues occur and the same files look like this:
/proc/asound/card2/pcm0p/sub0/sw_params:

Code: Select all

tstamp_mode: NONE period_step: 1 avail_min: 661 start_threshold: 1 stop_threshold: 131072 silence_threshold: 0 silence_size: 0 boundary: 1073741824

/proc/asound/card2/pcm0p/sub0/hw_params:

Code: Select all

access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 1764 buffer_size: 131072

Is it possible to achieve the same behavior as with PulseAudio on the OSs which don't have it? For example by changing some configuration files (.asoundrc etc). Is it possible to enable MMAP mode without necessarily installing PulseAudio?
Thanks!

[Rémi Denis-Courmont]

No, VLC cannot use MMAP mode. It wouldn't make sense for VLC to use it.

[peppy.player]

Does it mean that only PulseAudio can set the MMAP mode? Does it also mean that there is the issue in VLC in RW mode and I need to open the bug?
Thanks!

[Rémi Denis-Courmont]

If RW mode does not work properly, then that's a driver bug, though it's far from certain that that's the problem. There are no reasons for VLC to use MMAP mode ever.

[peppy.player]

OK, filed the bug report:
https://github.com/raspberrypi/linux/issues/4563