Access to DAC lost

[ceejayemm]

RPi3B+, IQaudIO Pi-DigiAMP+ (with unmute), i20230918 updated to 20231022

I originally reported something similar to this as #1411 but the current position has now changed such that it only seems to be contact with the DAC which is lost after a period of inactivity. I have full access to the web app and via SSH. but not any output via the DAC. As can be seen from the Player / Music Player Daemon log snippet below, I was using this system successfully yesterday afternoon until 16:27 at which time I simply stopped the player, I did not power off the system or do anything else with it until I came back to use it at 09:05 this morning. The system produced no audio output and on checking the Daemon log snippet I found the following:

Oct 28 16:27:06 RAConservatory mpd[844]: player: played "http://192.168.86.250:9790/minimstreamer/*/TESTR2/"
Oct 29 09:05:19 RAConservatory mpd[844]: exception: Failed to open "IQaudIODAC" (alsa); Failed to open ALSA device "hw:0,0": Input/output error
Oct 29 09:05:19 RAConservatory mpd[844]: exception: Failed to open "IQaudIODAC" (alsa); Failed to open ALSA device "hw:0,0": Input/output error
Oct 29 09:05:19 RAConservatory mpd[844]: player: problems opening audio device while playing "http://192.168.86.250:9790/minimstreamer/*/TESTR2/"
Oct 29 09:05:23 RAConservatory mpd[844]: exception: Failed to open "IQaudIODAC" (alsa); Failed to open ALSA device "hw:0,0": Invalid argument
Oct 29 09:05:23 RAConservatory mpd[844]: exception: Failed to open "IQaudIODAC" (alsa); Failed to open ALSA device "hw:0,0": Invalid argument

So why, with no activity on my part, has access to the DAC been lost ? A reboot fixes the problem but this shouldn't be happening. And, perhaps more importantly, how do I convince my wife that I haven't 'been fiddling again' with the radio setup that she like to listen to most of the day ;-)

Chris

[ceejayemm]

Sorry, I forgot to mention above, when the system is rebooted it invariably starts up with the volume at 100%, irrespective of where it was set previously, thus either giving a heart attack or instant loss of hearing (making listening a moot point !).

Chris

[kan-ibal]

it invariably starts up with the volume at 100%

See GUI volume always returns to 100% #1395

[ceejayemm]

@kan-ibal
Thanks. Having rebooted and with audio output playing (now at normal levels) I ran:

alsactl restore
alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
alsactl: set_control:1475: Cannot write control '2:0:0:Max Overclock PLL:0' : Device or resource busy
alsactl: set_control:1475: Cannot write control '2:0:0:Max Overclock DSP:0' : Device or resource busy
alsactl: set_control:1475: Cannot write control '2:0:0:Max Overclock DAC:0' : Device or resource busy

I get

alsa-lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2

as you do in #1395 but I am not sure if the other lines are due to the player currently active or not.

Chris

[ceejayemm]

Further, I am seeing errors like these in the output from journalctl -xe

Oct 29 09:46:48 RAConservatory kernel: pcm512x 1-004c: No SCLK, using BCLK: -2
Oct 29 09:46:50 RAConservatory kernel: pcm512x 1-004c: ASoC: error at snd_soc_component_update_bits on pcm512x.1-004c
for register: [0x0000013e] -5
Oct 29 09:46:50 RAConservatory websocket-server.py[2028]: amixer: Invalid command!
Oct 29 09:46:50 RAConservatory kernel: pcm512x 1-004c: ASoC: error at snd_soc_component_update_bits on pcm512x.1-004c
for register: [0x0000013d] -121
Oct 29 09:46:50 RAConservatory kernel: pcm512x 1-004c: ASoC: error at snd_soc_component_update_bits on pcm512x.1-004c
for register: [0x0000013e] -5
Oct 29 09:46:53 RAConservatory sudo[2039]: http : PWD=/srv/http ; USER=root ; COMMAND=/srv/http/bash/status.sh withdisplay
Oct 29 09:46:53 RAConservatory sudo[2039]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=33)
Oct 29 09:46:53 RAConservatory sudo[2038]: http : PWD=/srv/http ; USER=root ; COMMAND=/srv/http/bash/status.sh withdisplay
Oct 29 09:46:53 RAConservatory sudo[2038]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=33)
Oct 29 09:46:54 RAConservatory sudo[2038]: pam_unix(sudo:session): session closed for user root
Oct 29 09:46:54 RAConservatory sudo[2039]: pam_unix(sudo:session): session closed for user root
Oct 29 09:46:55 RAConservatory websocket-server.py[2282]: amixer: Invalid command!
Oct 29 09:46:55 RAConservatory kernel: pcm512x 1-004c: ASoC: error at snd_soc_component_update_bits on pcm512x.1-004c for
register: [0x0000013d] -121
Oct 29 09:46:55 RAConservatory kernel: pcm512x 1-004c: ASoC: error at snd_soc_component_update_bits on pcm512x.1-004c for
register: [0x0000013e] -121

Chris

[ceejayemm]

@rern
This is getting increasingly annoying - is there anything you can do about please ? I have had to reboot several times today as the DAC has 'gone missing' a lot more today than it has before.

Chris

[ceejayemm]

@rern
Still an issue with i20231022 updated to 20231111.

Chris

[ceejayemm]

Hardware still as noted at top of this thread.

Updated to 20231118 today and played web radio all morning, no issues. Stopped player (pressed stop button on top bar of Playback page) for lunch and went to play again about 2 hours later (press play button on top bar) but no audio output. Rebooted several times but no joy. Powered off RPi at wall socket and restarted, audio output as expected. Has the same effect if the centre of artwork is used instead.

This is driving me nuts - once rAudio won't play any attempt is futile until a full poweroff / restart is done. I have no idea why this is happening except to say that various ASoC errors (as noted above) are reported (via 'dmesg --follow' or 'journalct -xe') when this occurs.

@rern - can you put me out of my misery please !!!!

Chris

[rern]

Hi Chris,

Try the DAC with another RPi and the RPi with another DAC.

[ceejayemm]

@rern
Thanks for your comments above.

I recently changed to the DigiAMP+ and now it turns out that there are two variant of this DAC. The original (black circuit board) variant made by originally by IQaudIO and the newer (green circuit board) variant now made by RaspberryPI after their takeover of IAQaudIO a few years ago. Given that I only ordered this new DAC a month or so ago I assumed (not then knowing the colour variants) that I had a DAC made by Raspberry PI but in fact I had actually been delivered the original IQaudIO black circuit board DAC variant.

In addition there are three use cases with this DAC - the 'standard' Amp, Amp (with auto mute) and Amp (with unmute). In rAudio there are also options to select each of these use cases for the original IQaudIO AMP and the (RaspberryPI) IQaudIO PI-DigiAMP+ variants, making a total of six Audio-I2S options to choose from.

Given my, erroneous, assumption that I had a PI DigiAMP+ I originally chose the IQaudIO PI-DigiAMP+ option and also learnt the hard way that this DAC is also muted (?) out of the box. When I found out about this I chose the 'PI DigiAMP+ (with unmute)' option which appeared to work - but obviously didn't completely as this seems to the cause of the errors reported above as the DAC seemed to work correctly when first booted but not when resuming from a non-use period. I then learnt about the differences between the IQaudIO and Pi IQaudIO variants and switched the Audio-I2S option to 'IQaudIO AMP (with unmute)'. The unmute version 'does seem' to allow the DAC to recognise a resume from a non-use period and thus no error.

In addition I modified the /boot/config.txt file as follows:

disable_overscan=1
disable_splash=1
#dtoverlay=rpi-digiampplus,unmute_amp
dtoverlay=iqaudio-dacplus,auto_mute_amp
dtparam=i2c_vc_baudrate=50000
dtparam=i2s=on

I had to comment out the 3rd line and add the fourth line for the IQaudIO AMP. The fifth line is to provide a workaround to allow the RPi Official 7in Touchscreen to work correctly with an RPi 3B/B+ in my installation. The rest of this file is as provided by rAudio.

In the short term this seems to have removed, for me, the various ASoC errors noted above however I am still getting the Python websocket errors reported in #1473

I have spent some time detailing all of the above in order to help anybody else who should come across this problem in future.

Chris