The VideoLAN Forums

Posted: **20 Aug 2021 22:55**

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!

Posted: **22 Aug 2021 09:02**

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

Posted: **23 Aug 2021 00:33**

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!

Posted: **23 Aug 2021 16:59**

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

Posted: **23 Aug 2021 22:24**

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.

Posted: **24 Aug 2021 20:37**

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.

Posted: **25 Aug 2021 18:26**

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

Posted: **29 Aug 2021 20:30**

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!

Posted: **30 Aug 2021 14:33**

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

Posted: **31 Aug 2021 16:34**

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!

Posted: **31 Aug 2021 19:28**

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.

Posted: **04 Sep 2021 18:58**

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

The VideoLAN Forums

Issues with DACs on Linux

Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux

Re: Issues with DACs on Linux