Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
simonvanderveldt opened this issue Oct 19, 2019 · 1 comment
Assignees

Comments

@simonvanderveldt
Copy link
Member

simonvanderveldt commented Oct 19, 2019

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.

@simonvanderveldt simonvanderveldt self-assigned this Oct 19, 2019
@okyeron
Copy link

okyeron commented Oct 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants