Following up to No Audio after update to matrix - #5 by grahamh
(see also Raspotify/librespot not working after November update - #5 by oebeledrijfhout)
Finally librespot implemented a workaround for an alsa buffer issue in ERROR ALSA function 'snd_pcm_hw_params_set_buffer_time_near' failed with error 'EINVAL: Invalid argument' on playback on Vero4K · Issue #895 · librespot-org/librespot · GitHub , so raspotify/librespot starts again and can play audio.
However, I now have audio issues: there are lots of dropouts, each about half a second of silence. Irregularly distributed, sometimes there is only one second between two dropouts, sometimes its multiple seconds.
This is my syslog, with librespot in verbose mode:
Note the warning of audio issues, which I suspect could be the case here:
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Desired Frames per Buffer: 22050
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Error setting the device's Buffer size: ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Desired Buffer Frame range: 4410 - 22050
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Actual Buffer Frame range as reported by the device: 32 - 131072
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Failed to set Buffer and/or Period size, falling back to the device's defaults.
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] You may experience higher than normal CPU usage and/or audio issues.
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Actual Frames per Buffer: 131072
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Actual Frames per Period: 256
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Period Buffer size in bytes: 1024
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_playback::audio_backend::alsa] Period Buffer capacity: 1024
Jan 22 15:22:56 osmc librespot[23103]: [2022-01-22T14:22:56Z TRACE librespot_connect::spirc] ==> kPlayStatusPlay
Jan 22 15:22:56 osmc kernel: aml_meson_snd_card aml_sound_meson:
area=ffffff8008d01000,addr=1503657984,bytes=524288,rate:44100, channels:2, subformat:0
Jan 22 15:22:56 osmc kernel: snd_spdif_dai: aml_hw_iec958_init,runtime->rate=44100, runtime->channels=2
same source mode(1), stream format=2 CH PCM
Jan 22 15:22:56 osmc kernel: hdmitx: audio: aout notify rate 44100
Jan 22 15:22:56 osmc kernel: hdmitx: audio: aout notify size 16
Jan 22 15:22:56 osmc kernel: hdmitx: audio: hdmi_ch: 0 speaker_layout: 0
I tested playing music without spotify, using mpv, with similar dropouts, and a similar error meesage:
# mpv [...].flac
Playing: XXXX.flac
(+) Audio --aid=1 (flac 2ch 44100Hz)
[...]
[ao/alsa] Unable to set buffer time near: Invalid argument
AO: [alsa] 44100Hz stereo 2ch s16
So it seems it is related to alsa somehow.
Hmmm. And just checking - does Kodi play music without problems?
Yes, I didn’t notice any problems playing music or videos in Kodi.
aplay doesn’t have any issues, here.
osmc@vero4kp2:~$ aplay -v -Dplughw:0,0 --buffer-size 22050 /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0
1 <- 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 20480
period_size : 4096
period_time : 85333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 20480
stop_threshold : 20480
silence_threshold: 0
silence_size : 0
boundary : 1342177280
Slave: Hardware PCM card 0 'AML-MESONAUDIO' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 20480
period_size : 4096
period_time : 85333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 20480
stop_threshold : 20480
silence_threshold: 0
silence_size : 0
boundary : 1342177280
appl_ptr : 0
hw_ptr : 0
Invalid argument suggests the calling programme has an issue.
I did some more debugging:
- Your example worked here too, but it being so short, that could have simply not been enough time for a dropout to appear.
- With a longer wav (44100 Hz) the dropouts happened with aplay as well:
aplay -v -Dplughw:0,0 --buffer-size 22050 test.wav
- However: when I manually resampled the long wav file to 48000 Hz, and tried again, it worked flawlessly. (
ffmpeg -i test.wav -ar 48000 test48.wav; aplay -v -Dplughw:0,0 --buffer-size 22050 test48.wav )
Quite, but the verbose logging indicates it found a sensible buffer and period size which raspotify was unable to do.
We may have more than one problem to fix, then. Let me try that.
Here is a 44.1kHz file playing for 8 minutes without issues:
osmc@vero4kp2:/mnt/1Text4/Music/Test files$ aplay -v Pitsburg\ Encore.wav -Dhw:0,0 --buffer-size 22050
Playing WAVE 'Pitsburg Encore.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 0 'AML-MESONAUDIO' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 20480
period_size : 4096
period_time : 92879
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 20480
stop_threshold : 20480
silence_threshold: 0
silence_size : 0
boundary : 1342177280
appl_ptr : 0
hw_ptr : 0
So not sure what to suggest, now.
I did some further testing:
- switched from HDMI to line-out on the vero 4k+ : 44100Hz works!
- back to HDMI, configured kodi to force 44.1 khz: playing audio produces dropouts even in kodi!
So, it seems to be very specific to playing 44100 Hz audio via HDMI
What was your configuration?
That’s not possible. There’s no line-out setting.
Let me rephrase it: with “switch” I meant the following physical action: my original setup was via HDMI audio out to the TV then to speakers. I unplugged the speakers from the TV. Then I plugged in my speakers directly into the vero.
I’m just playing through HDMI to my TV. Do you get drop-outs when using the TV’s internal speaker(s)?
And are you still getting those ‘invalid argument’ type messages?
We’ll need some more information. Please turn on debug logging, set Kodi audio output to Best match, reboot and play something with a 44.1k samplerate with whatever apps are causing problems. Upload logs.
Also post the output of aplay -l and aplay -L and the contents of ~/.asoundrc (if any) and /etc/asound.conf (if any).
Done.
I just played a .flac with 44100 Hz directly in kodi, dropouts on HDMI.
https://paste.osmc.tv/uxuqiqohel
For the aplay, asoundrc:
osmc@osmc:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: AMLMESONAUDIO [AML-MESONAUDIO], device 0: I2S T9015-audio-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLMESONAUDIO [AML-MESONAUDIO], device 1: SPDIF dit-hifi-1 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: AMLMESONAUDIO [AML-MESONAUDIO], device 2: PCM pcm2bt-pcm-2 []
Subdevices: 1/1
Subdevice #0: subdevice #0
osmc@osmc:~$ aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
btaudio
Bluetooth Audio
jack
JACK Audio Connection Kit
pulse
PulseAudio Sound Server
default:CARD=AMLMESONAUDIO
AML-MESONAUDIO,
Default Audio Device
sysdefault:CARD=AMLMESONAUDIO
AML-MESONAUDIO,
Default Audio Device
hdmi:CARD=AMLMESONAUDIO,DEV=0
AML-MESONAUDIO,
HDMI Audio Output
dmix:CARD=AMLMESONAUDIO,DEV=0
AML-MESONAUDIO,
Direct sample mixing device
dmix:CARD=AMLMESONAUDIO,DEV=1
AML-MESONAUDIO,
Direct sample mixing device
dmix:CARD=AMLMESONAUDIO,DEV=2
AML-MESONAUDIO,
Direct sample mixing device
dsnoop:CARD=AMLMESONAUDIO,DEV=0
AML-MESONAUDIO,
Direct sample snooping device
dsnoop:CARD=AMLMESONAUDIO,DEV=1
AML-MESONAUDIO,
Direct sample snooping device
dsnoop:CARD=AMLMESONAUDIO,DEV=2
AML-MESONAUDIO,
Direct sample snooping device
hw:CARD=AMLMESONAUDIO,DEV=0
AML-MESONAUDIO,
Direct hardware device without any conversions
hw:CARD=AMLMESONAUDIO,DEV=1
AML-MESONAUDIO,
Direct hardware device without any conversions
hw:CARD=AMLMESONAUDIO,DEV=2
AML-MESONAUDIO,
Direct hardware device without any conversions
plughw:CARD=AMLMESONAUDIO,DEV=0
AML-MESONAUDIO,
Hardware device with all software conversions
plughw:CARD=AMLMESONAUDIO,DEV=1
AML-MESONAUDIO,
Hardware device with all software conversions
plughw:CARD=AMLMESONAUDIO,DEV=2
AML-MESONAUDIO,
Hardware device with all software conversions
usbstream:CARD=AMLMESONAUDIO
AML-MESONAUDIO
USB Stream Output
osmc@osmc:~$ cat /etc/asound.conf
cat: /etc/asound.conf: No such file or directory
osmc@osmc:~$ cat ~/.asoundrc
cat: /home/osmc/.asoundrc: No such file or directory
Change your GUI resolution to 1080p.
Wow. This seems to have fixed it. Surprising. Thanks!
May I ask, what is the technical reason behind this?
If I knew, I would be happy. 
It’s something that came with the 4.9 kernel.
It could be that this is TMDS clock related.
1 Like