You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases USB soundcards get ALSA card ID 0, which is the one we use to run JACK. This means sound is going to the wrong soundcard, or in some cases (MIDI devices without audio) JACK is unable to start.
I've been unable to reproduce this on the buildroot image, it might also not happen on the norns hardware/image itself but only when running on a regular RPi with raspbian, still gathering info.
Output on norns running the buildroot image:
# cat /proc/asound/cards
0 [sndrpimonome ]: snd_rpi_monome - snd_rpi_monome
snd_rpi_monome
1 [eX ]: USB-Audio - ESI MIDIMATE eX
Ploytec GmbH ESI MIDIMATE eX at usb-3f980000.usb-1.1, full speed
#
Alternatively we could look into making sure monome-snd always gets ID 0. The advantage to this would be that there would be no need to change any config in case the norns stack is used with a different setup/board which uses a different soundcard. The OS would just need to be configured correctly to ensure the desired soundcard is at ID 0.
The text was updated successfully, but these errors were encountered:
Reposting this from the lines thread. (and adding more details as reference material)
I was able to "fix" the load order with the following:
create or edit /etc/modprobe.d/alsa-base.conf
then add
# This sets the index value of the cards but doesn't reorder.
# index of -2 instructs ALSA to never use a card as primary
options snd_usb_audio index=-2
options snd_soc_rpi_proto index=0
# Does the reordering.
options snd slots=snd_soc_rpi_proto, snd_usb_audio
Further testing just now - this "reordering" seems to happen on a base install of Buster with only my soundcard setup - in my case this is the WM8731 codec on the Fates DIY board.
I observe the problem plugging in A Waldorf Blofeld and a Teensy midi device and rebooting.
pi@raspberrypi:~ $ cat /proc/asound/cards
0 [Blofeld ]: USB-Audio - Blofeld
Waldorf Music GmbH Blofeld at usb-3f980000.usb-1.1.3, full speed
1 [twohost ]: USB-Audio - twohost
denkioto twohost at usb-3f980000.usb-1.1.2, full speed
2 [sndrpiproto ]: snd_rpi_proto - snd_rpi_proto
snd_rpi_proto
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 2: sndrpiproto [snd_rpi_proto], device 0: WM8731 HiFi wm8731-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
According to this archilinux/ALSA doc, /etc/asound.conf could be configured to the specific hardware device
This looked promising:
In most cases it is recommended to use sound card names instead of number references, which also solves boot order problem. Therefore the following would be correct for the above example.
But... the devices are still ordered dynamically, so the primary sound card can change card positions.
So using snd slots in /etc/modprobe.d/alsa-base.conf (as above) appears to have the most consistent way of ensuring which card gets assigned to primary
Found a decent ALSA reference that mentions the "slots" here
Problems with alsa.conf and udev
On modern GNU/Linux systems, udev takes care of discovering hardware and loading/unloading Alsa. There is one drawback to udev. Udev will load Alsa modules in an undefined order. After each reboot or plugging/unplugging a device, there is no guarantee that a device is renamed using the same hw:x,y numbers. For example, if you have two USB devices on your systems, for example an Audeon USB and an Edirol UA-25, after each reboot, a card can be "hw:0,0" and the other "hw:1,0", each time randomly.
In some cases USB soundcards get ALSA card ID 0, which is the one we use to run JACK. This means sound is going to the wrong soundcard, or in some cases (MIDI devices without audio) JACK is unable to start.
I've been unable to reproduce this on the buildroot image, it might also not happen on the norns hardware/image itself but only when running on a regular RPi with raspbian, still gathering info.
Output on norns running the buildroot image:
not sure why yet.
I guess the simplest way would be to use
hw:sndrpimonome
instead ofhw:0
in the JACK service https://github.com/monome/norns-image/blob/master/config/norns-jack.service#L11Alternatively we could look into making sure monome-snd always gets ID 0. The advantage to this would be that there would be no need to change any config in case the norns stack is used with a different setup/board which uses a different soundcard. The OS would just need to be configured correctly to ensure the desired soundcard is at ID 0.
The text was updated successfully, but these errors were encountered: