snapcast
snapcast copied to clipboard
error "Stream URI must have a name" when trying to use line-in via alsa stream on Raspberry Pi
Describe the bug I've set up snapserver and two snapclients, and they play great using shairport using a pipe, but when I try to additionally add an input stream from an alsa device, snapcast refuses to start and gives an error "Stream URI must have a name"
Steps to Reproduce
- Create two stream entries as follows: source = alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3 source = pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
- Start snapserver.service
- Observe syslog
NOTE: I tried various options for the device specification for the alsa line-in from my USB soundcard; using the "hw:3,1,0" specification didn't seem to work at-all (no such file), but it seems to get further if I specify the device path itself. Environment details
- OS: Debian 11 (bullseye) Raspberry Pi OS
- Snapcast version: 0.23.0+dfsg1-1
- Installed from apt repository
Attach logfile if applicable
Generate logs with snapclient --logfilter debug
or snapserver --logging.filter debug
if possible and paste them in the following codeblock
2023-04-12 22-20-43.566 [Info] (main) Adding source: alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
2023-04-12 22-20-43.567 [Info] (main) Adding source: pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
2023-04-12 22-20-43.568 [Notice] (init) Settings file: "/home/pi/.config/snapserver/server.json"
2023-04-12 22-20-43.581 [Info] (Avahi) Adding service 'Snapcast'
2023-04-12 22-20-43.591 [Debug] (parse) StreamUri: alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
2023-04-12 22-20-43.592 [Debug] (parse) StreamUri decoded: alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
2023-04-12 22-20-43.592 [Debug] (parse) scheme: 'alsa' tmp: '//?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3'
2023-04-12 22-20-43.592 [Debug] (parse) host: '?name=linein&sampleformat=48000:16:2&device=' tmp: '/dev/snd/controlC3' path: '/dev/snd/controlC3'
2023-04-12 22-20-43.593 [Notice] (Server) Server::start: Stream URI must have a name
2023-04-12 22-20-43.594 [Error] (main) Exception: Stream URI must have a name
2023-04-12 22-20-43.596 [Notice] (main) Snapserver terminated.```
2023-04-12 22-20-43.566 [Info] (main) Adding source: alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
Add a third "/" after alsa. Try using the following:
alsa:///?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
Thanks, that gets me a step further. I still couldn't get the service to start with the device specified above, but I replaced the path with the specification in the documentation, hw:#,#,# using the output of aplay -l, realised that the line-in was only going to have a single audio channel, and set the sample rate to match that of the other input. The service now starts using the following entries in snapserver.conf
source = alsa:///?name=linein&sampleformat=44100:16:1&device=hw:3,0,0
source = pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
From what I can see, my USB line-in is device #0 on card 3:
$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: Device [USB Audio Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
Unfortunately, snapserver still doesn't detect anything but silence on that device:
2023-04-14 19-48-20.650 [Info] (AlsaStream) No data availabale, playing silence.
I have a cable connected to the the 3.5mm output of an Amazon Echo Dot, the other end of which goes into the red input on a USB C-Media Electronics, Inc. Audio Adapter (Unitek Y-247A) adapter.
Using arecord, I can confirm that the device is able to capture audio using the same device specification by listening to the resulting file:
arecord -d 10 -D hw:3,0,0 -r 44100 -f S16_LE test.wav
Also, arecord --dump-hw-params shows the following capabilities, in case that's useful:
HW Params of device "hw:3,0,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 16
CHANNELS: 1
RATE: [44100 48000]
PERIOD_TIME: [1000 1000000]
PERIOD_SIZE: [45 48000]
PERIOD_BYTES: [90 96000]
PERIODS: [2 1024]
BUFFER_TIME: [1875 2000000]
BUFFER_SIZE: [90 96000]
BUFFER_BYTES: [180 192000]
TICK_TIME: ALL
--------------------
Out of curiosity, set the hw device in the snapserver config to 3.
source = alsa:///?name=linein&sampleformat=44100:16:1&device=hw:3
Unfortunately the service doesn't start using the option device=hw:3
what is the output of arecord -l
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
Try using that device and test if you're receiving silence
On Tue, Apr 25, 2023, 05:59 Dominic Watkins @.***> wrote:
$ arecord -l **** List of CAPTURE Hardware Devices **** card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0
— Reply to this email directly, view it on GitHub https://github.com/badaix/snapcast/issues/1122#issuecomment-1521513160, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKSNLVQSSN6SKBMPQYMKODXC6N6JANCNFSM6AAAAAAW4HA6A4 . You are receiving this because you commented.Message ID: @.***>
Unfortunately itstill appears to only detect silence. I think the devices changed around when I rebooted, so what was once card 3 is now card 1, and yields the same result as before. I've tried other device specifications, and this appears to be the only one which allows the Snapcast service to start, but it never detects anything but silence, even though I'm able to record a file form the same device.
source = alsa:///?name=linein&sampleformat=44100:16:1&device=hw:1,0,0
Is that the only source defined? It's quite odd that you're getting silence if you're able to directly record audio.
On Thu, Apr 27, 2023, 14:11 Dominic Watkins @.***> wrote:
Unfortunately itstill appears to only detect silence. I think the devices changed around when I rebooted, so what was once card 3 is now card 1, and yields the same result as before. I've tried other device specifications, and this appears to be the only one which allows the Snapcast service to start, but it never detects anything but silence, even though I'm able to record a file form the same device.
source = alsa:///?name=linein&sampleformat=44100:16:1&device=hw:1,0,0
— Reply to this email directly, view it on GitHub https://github.com/badaix/snapcast/issues/1122#issuecomment-1526120106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKSNLQRGXODNY2MKIIXBHDXDKZDZANCNFSM6AAAAAAW4HA6A4 . You are receiving this because you commented.Message ID: @.***>
I'm also using shairport-sync with the following configuration in snapserver.conf to create the fifo for it to play in to:
source = pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
Snapserver does start with both the fifo pipe and the alsa device defined, it just fails to detect anything but silence. What's even stranger, is that running the process with strace shows that it's opening the exact same device as that which arecord is using to successfully record a 10-second audio file as discussed beforehand.
I'm not familiar with SharePoint sync, but if you're ok doing some testing I'd like you to try removing the FIFO and launch with just the alsa device, or move the alsa device higher in priority in the meta.
I've got an open issue where I get blocking silence when feeding the snapserver FIFO with audio coming from a snap server client.
On Wed, May 10, 2023, 11:31 Dominic Watkins @.***> wrote:
I'm also using shairport-sync with the following configuration in snapserver.conf to create the fifo for it to play in to:
source = pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
Snapserver does start with both the fifo pipe and the alsa device defined, it just fails to detect anything but silence. What's even stranger, is that running the process with strace shows that it's opening the exact same device as that which arecord is using to successfully record a 10-second audio file as discussed beforehand.
— Reply to this email directly, view it on GitHub https://github.com/badaix/snapcast/issues/1122#issuecomment-1542412786, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEKSNLUBDDJGB27O25NCJ4DXFOYDRANCNFSM6AAAAAAW4HA6A4 . You are receiving this because you commented.Message ID: @.***>
I'm happy to test, and that does indeed seem to work, at least partially.
Commenting out the configuration for the /tmp/snapfifo pipe and leaving just the alsa configuration in place as below, I can plug in a device via the 3.5mm USB capture device and it plays to my Snapcast clients when I start the service in debug mode!
source = alsa:///?name=linein&send_silence=false&idle_threshold=100&sampleformat=44100:16:1&device=hw:1,0,0
What is bizarre, however, is that the same configuration as above fails to start the service in the usual automated manner via sudo service snapserver start
, resulting in the following entry in /var/log/daemon.log. I have verified the output of arecord -l
, and this is definitely the correct device reference. Restarting multiple times in debug mode and then attempting to start the service normally yields the same results.
May 16 19:47:37 pegasus snapserver[37732]: ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card
Try removing the sub device from the statement and see if the service starts.
source = alsa:///?name=linein&send_silence=false&idle_threshold= 100&sampleformat=44100:16:1&device=hw:1,0
As before, this configuration doesn't allow the service to start as a daemon, but I can start snapserver from the command line with the debug option (as the user 'pi') and get it to play via the USB line in device. When I enable the pipe for shairport-sync as well, however, it fails to play both together, and only sends the audio from shairport-sync to the snapclients.
I'm going to reinstall with mopidy in the hope that this is either a permissions issue, or some other kind of configuration problem. I'll keep the microsd card that this installation is on, in case it's useful in future. Thanks for all the suggestions thus far!
I have a similar issue. I am using line in on the motherboard sound card running with debian bookworm on a headless server.
I have the following in the stream section of snapserver.conf
source = pipe:///tmp/snapfifo?name=default
source = alsa:///?name=linein&device=hw:1,0,0
Like glymph, I cannot start the service using systemd but can run using the commandline. Unlike glymph I can select and hear both streams on all clients, though on the console is the following
2023-08-10 12-29-14.671 [Info] (AlsaStream) No data availabale, playing silence.
I would love to be able to start it using systemd. Thanks to everyone involved in snapcast it is great.
I would love to be able to start it using systemd. Thanks to everyone involved in snapcast it is great.
What is stopping it from running as a service under systemd?
Does it work if you restart the service once the system is up and running? i.e. could it be a problem with the sound device not being ready in time during startup?