Closed everydayanchovies closed 2 years ago
Thanks for the post. I edited it slightly for layout.
Could you clarify this please:
This happens with all values of the disable standby mode setting. The device wakes up immediately after starting shairport.
Do these two sentences refer to when you're using the dmix
device only? In other words, is it the case that when you output from Shairport Sync to hw:2
, the disable_standby_mode
setting is correctly observed; and that when Shairport Sync outputs to the dmix
device, the disable_standby_mode
is totally ignored and the DAC never gets into standby mode?
Yes, I am now running through all my tests again to reproduce but as I have to wait for the device to go to standby it will take a while.
Using hw:2 and no standby preference (commented out):
$ sudo systemctl stop shairport-sync.service
$ cat /proc/asound/card2/pcm0p/sub0/status
-> closed
$ sudo systemctl start shairport-sync.service
-> state: RUNNING [...]
After a couple of minutes, the DAC has still not entered standby mode. (Contradicting what I've said so far, sorry, I must have misremembered.) Killing shairport immediatly puts it in standby mode. I haven't connected to it, and so nothing is playing. Reading in the codebase I expect it to start idle and only wake on playback, but maybe I am mistaken. Furthermore I didn't find a timeout to standby, but only a silence threshold.
So I now wonder why the DAC doesn't enter standby in this standard configuration (no dmix).
I then changed the config to use the Master mix channel on the DAC instead of softvol.
Then I played something, and stopped playback. I noticed shairport correctly entered am_inactive mode, but the DAC is still awake.
0.000483482 "rtsp.c:2579" Connection 1: TEARDOWN a PTP stream.
0.000327296 "player.c:1670" Cancelling AP2 timing, control and audio threads...
0.000052259 "player.c:1673" Connection 1: Delete Realtime Audio Stream thread
0.000169760 "rtp.c:1865" Realtime Audio Receiver Cleanup Start.
0.000125685 "rtp.c:1868" Connection 49290: closing realtime audio port 2249835881
0.000038815 "rtp.c:1870" Realtime Audio Receiver Cleanup Done.
0.000160722 "player.c:1687" Connection 31: Delete AirPlay 2 Control thread
0.000385111 "rtp.c:1634" Connection 1: AP2 Control Receiver Cleanup.
0.000103018 "rtp.c:1636" Connection 1: UDP control port 51492 closed.
0.000143130 "rtp.c:1325" Connection 1: Clear anchor information.
0.000503019 "player.c:1742" Connection 1: player terminated.
0.000182296 "player.c:3387" pend
0.000099981 "rtsp.c:2584" Connection 1: TEARDOWN phase one complete
10.000236624 "activity_monitor.c:87" aend
0.000127482 "activity_monitor.c:172" am_state: am_inactive
$ cat /proc/asound/card2/pcm0p/sub0/status
-> state: RUNNING
owner_pid : 522285
trigger_time: 332577.091849598
tstamp : 332741.721392098
delay : 2056
avail : 129016
avail_max : 129016
-----
hw_ptr : 7260216
appl_ptr : 7262272
Note, this is also interesting:
$ ps au | grep 522285
-> max 522908 0.0 0.0 5912 628 pts/1 S+ 14:56 0:00 grep --color=auto 522285
I'm using a self-compiled build from the development branch: 4.1-dev-388-g16c5874d-AirPlay2-alac-OpenSSL-Avahi-ALSA-jack-soxr-convolution-metadata-sysconfdir:/etc
Thanks for the fast reply.
Thanks for the information. Here is what I think should be happening:
If there is no disable_standby_mode
set, then by default it is off. That means that the Shairport Sync ("SPS") will stop sending audio to it as soon as the audio programme stops. In this mode, the am_state
has no effect on the DAC's standby mode: if audio is coming from the source, it'll be sent to the DAC; if not, no audio will be sent.
If disable_standby_mode
is set to "auto"
, then SPS will keep the DAC out of the standby mode only when the am_state
is am_active
. It does this by ensuring the the DAC is fed with audio, sending silent frames if necessary, while the am_state
is am_active
. If disable_standby_mode
is "yes"
or "always"
, then SPS will keep the DAC out of the standby mode all the time, sending silent frames whenever necessary.
Now, when SPS is driving the DAC directly ("hw:2"
), it controls what goes to the DAC. However, when SPS is driving the dmix
device, it is outputting to the dmix
device and not to the DAC. It is up to the dmix
device as to what it sends to the DAC hardware – SPS has no control over that, I'm afraid.
But there is another aspect to this. "Standby" is different to "closed" (i.e. standby ≠ closed). That is, a DAC could be open and could enter and leave standby mode while remaining open, sometimes resulting in audible clicks or pops.
Does that correspond with what you are seeing?
Yes, that clears things up a lot.
But there is another aspect to this. "Standby" is different to "closed" (i.e. standby ≠ closed). That is, a DAC could be open and could enter and leave standby mode while remaining open, sometimes resulting in audible clicks or pops.
I was concerned that the DAC was recieving silent frames while the device was open, but now I assume it does no harm to keep it open.
Thank you!
I found the issue (in my opinion it is an issue): if use_precision_timing is "yes" then the DAC never sleeps.
That makes sense, but I didn't expect that to happen.
My DAC now sleeps :)
Very interesting, thanks. Just to be clear, are your referring to the real DAC — hw:2
— or the dmix
device?
Both, actually! It enters sleep within a second of playback stopping with use_precision_timing="no".
Thanks. I must look into that some more.
Hi Mike,
Thanks a lot for your work.
I tried troubleshooting this error as far as I could but I'm stumped.
The situation:
This happens with all values of the disable standby mode setting. The device wakes up immediately after starting shairport.
I attach four files:
Let me know if I can give more info or debug something specific.
Cheers,
Max
Here is my alsa config:
Here is my shairport config: