search

monome / norns-image

79 stars 16 forks source link

Ensure JACK uses the monome-snd soundcard even when USB devices are plugged in #78

Open simonvanderveldt opened 4 years ago

simonvanderveldt commented 4 years ago

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
#

not sure why yet.

I guess the simplest way would be to use hw:sndrpimonome instead of hw:0 in the JACK service https://github.com/monome/norns-image/blob/master/config/norns-jack.service#L11

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.

okyeron commented 4 years ago

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.