error "Stream URI must have a name" when trying to use line-in via alsa stream on Raspberry Pi #1122
Comments
|
Add a third "/" after alsa. Try using the following:
|
|
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 From what I can see, my USB line-in is device #0 on card 3: Unfortunately, snapserver still doesn't detect anything but silence on that device:
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:
|
|
Out of curiosity, set the hw device in the snapserver config to 3.
|
|
Unfortunately the service doesn't start using the option device=hw:3 |
|
what is the output of arecord -l |
|
|
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
<#1122 (comment)>,
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.
|
|
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
<#1122 (comment)>,
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:
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
<#1122 (comment)>,
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!
What is bizarre, however, is that the same configuration as above fails to start the service in the usual automated manner via
|
|
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 Like glymph, I cannot start the service using systemd but can run using the commandline.
I would love to be able to start it using systemd. |
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? |
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
source = alsa://?name=linein&sampleformat=48000:16:2&device=/dev/snd/controlC3
source = pipe:///tmp/snapfifo?name=default&sampleformat=44100:16:2
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
Attach logfile if applicable
Generate logs with
snapclient --logfilter debugorsnapserver --logging.filter debugif possible and paste them in the following codeblockThe text was updated successfully, but these errors were encountered: