02-16-2024, 01:03 PM
Right, the receiver opens the audio device and leaves it open while its waiting for data packets from the sender.
The receiver daemon does not post a "play state" event indicating whether it's playing or not, and I'm not sure that state can be determined by an external program. I checked various ALSA blocks and no luck seeing an indication of play state.
# ALSA device block (card1 = Heaphone)
# ALSA commands
TRX Receiver source
https://github.com/bitkeeper/trx/blob/fe...urtis/rx.c
I did a quick test of the receiver in debug mode while sender is stopped and then playing and there were no NULL packets reported. In other words no obvious way to determine the play state from debug output.
I can add "Code a trx-rx event to indicate play state" to the TODO list but practically speaking its going to take another dev to do the investigation and work because of time constraints on my end.
The receiver daemon does not post a "play state" event indicating whether it's playing or not, and I'm not sure that state can be determined by an external program. I checked various ALSA blocks and no luck seeing an indication of play state.
# ALSA device block (card1 = Heaphone)
Code:
pi@pb1:~ $ ls /proc/asound/card1/pcm0p/sub0/
hw_params info prealloc prealloc_max status sw_params# ALSA commands
Code:
alsabat
alsabat-test
alsacap
alsactl
alsa-info
alsaloop
alsamixer
alsatplg
alsaucmTRX Receiver source
https://github.com/bitkeeper/trx/blob/fe...urtis/rx.c
I did a quick test of the receiver in debug mode while sender is stopped and then playing and there were no NULL packets reported. In other words no obvious way to determine the play state from debug output.
Code:
sudo killall trx-rx
sudo trx-rx -d plughw:1,0 -h 239.0.0.1 -p 1350 -m 128 -j 64 -f 1920 -R 45 -v 2I can add "Code a trx-rx event to indicate play state" to the TODO list but practically speaking its going to take another dev to do the investigation and work because of time constraints on my end.
