I've heard from someone else who seemed to know things that jack does add latency, but I haven't measured it myself... I'd be interested to read about this lack of latency. But latency aside jack can be a monumental hassle, don't get me started. I would totally run scsynth with -odac = hw:1,0, except scsynth is unresponsive to osc messages when I do that. With hw:0,0 it works. Some kind of bug. No one ever uses that portaudio mode in linux in the supercollider world, so its something of a surprise that it works at all. I think its in there for windows users. I'm going to file a bug re the hw:1,0 thing. Unfortunately my system (bananapi with armv7 processor) doesn't have a bios so I can't deactivate the onboard audio there. Disabling the hw:0,0 is sort of a last resort before I just rewrite my stuff in something other than supercollider, that doesn't require jack and actually allows selecting another audio device. I'm going to give that "options snd slots=snd_usb_audio" thing a try - hopefully good results. Will report back. Ben On 10/04/2015 04:47 PM, Paul Davis wrote: > Oh, one other thing. Using PortAudio will *not* reduce latency. JACK > does not add any latency. > > On Sun, Oct 4, 2015 at 6:46 PM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote: >> This can be hard to do. Why can't you tell software to use hw:1 ? >> >> Most system BIOS setup utilities can be used to disable onboard sound. >> Getting Linux to reorder them is also possible but can be complex >> depending on the types of devices (PCI, USB etc) >> >> On Sun, Oct 4, 2015 at 2:57 PM, ansible <bburdette@xxxxxxxxx> wrote: >>> I compiled supercollider to play through portaudio rather than jack, as it >>> usually does, in an attempt to reduce latency and hassle. It works for >>> audio device hw:0,0, but it doesn't work for hw:1,0. My problem is that on >>> my device hw:0,0 has horrible latency - 70ms - while hw:1,0 has 9ms latency, >>> much better. >>> >>> So what I'd like to do is reorder the audio devices, or disable the onboard >>> audio, and have my current hw:1,0 be the hw:0,0 device. Hopefully then >>> supercollider will work with it and I'll have those coveted low latency >>> numbers. This is on arch linux on a bananapi armv7 computer. >>> >>> So here's the output from aplay -l: >>> >>> ``` >>> [bananapi@lemaker ~]$ aplay -l >>> **** List of PLAYBACK Hardware Devices **** >>> card 0: sunxicodec [sunxi-CODEC], device 0: M1 PCM [sunxi PCM] >>> Subdevices: 1/1 >>> Subdevice #0: subdevice #0 >>> card 1: Pro [Sound Blaster X-Fi Go! Pro], device 0: USB Audio [USB Audio] >>> Subdevices: 1/1 >>> Subdevice #0: subdevice #0 >>> [bananapi@lemaker ~]$ >>> ``` >>> >>> According to the [alsa wiki][1], I should be able to reorder the devices >>> using a .conf file. See 'set the default sound card'. It gives the example >>> of this: >>> >>> ``` >>> /etc/modprobe.d/alsa-base.conf >>> >>> options snd_mia index=0 >>> options snd_hda_intel index=1 >>> ``` >>> >>> Ok so I made a file like that, but I only know the name of the usb driver, >>> not the onboard sound driver. lsmod reveals the following: >>> >>> ``` >>> [bananapi@lemaker ~]$ lsmod >>> Module Size Used by >>> snd_usb_audio 96225 0 >>> snd_hwdep 5757 1 snd_usb_audio >>> snd_usbmidi_lib 18033 1 snd_usb_audio >>> cdc_acm 20518 0 >>> spidev 6217 0 >>> spi_sun7i 17802 0 >>> sunxi_cedar_mod 9808 0 >>> mali_drm 2608 0 >>> drm 209226 1 mali_drm >>> mali 111427 0 >>> disp_ump 861 0 >>> ump 52415 2 mali,disp_ump >>> ap6210 584133 0 >>> ip_tables 12937 0 >>> x_tables 17443 1 ip_tables >>> ``` >>> >>> If I do "modprobe -r snd_usb_audio", then snd_hwdep and snd_usbmidi_lib both >>> disappear too, so they are all for the same device I think. That leaves >>> nothing for the driver name for the onboard audio. >>> >>> The alsa wiki says that the driver names should be in "cat >>> /proc/asound/modules" but I don't have that directory on my system. >>> >>> So anyway I made an alsa-base.conf file as directed, which looks like this: >>> >>> ``` >>> [bananapi@lemaker ~]$ cat /etc/modprobe.d/alsa-base.conf >>> options snd_usb_audio index=0 >>> options sunxicodec index=1 >>> [bananapi@lemaker ~]$ >>> ``` >>> >>> After creating that file and rebooting aplay just returns this. >>> >>> ``` >>> [bananapi@lemaker ~]$ aplay -l >>> **** List of PLAYBACK Hardware Devices **** >>> card 0: sunxicodec [sunxi-CODEC], device 0: M1 PCM [sunxi PCM] >>> Subdevices: 1/1 >>> Subdevice #0: subdevice #0 >>> [bananapi@lemaker ~]$ >>> ``` >>> >>> So this alsa-base.conf has the effect of making only the onboard audio >>> available instead of reordering. I most likely have the 'sunxicodec' name >>> wrong for the onboard audio, I'm just guessing at that, and have no idea >>> what the driver name for that is, if there even is one. I'm kind of >>> suspecting the audio device is part of a monolithic driver for the whole >>> system-on-chip, is that possible? >>> >>> [1]: >>> https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture >>> >>> >>> >>> -- >>> View this message in context: http://linux-audio.4202.n7.nabble.com/make-alsa-device-hw-1-0-be-hw-0-0-somehow-tp97402.html >>> Sent from the linux-audio-user mailing list archive at Nabble.com. >>> _______________________________________________ >>> Linux-audio-user mailing list >>> Linux-audio-user@xxxxxxxxxxxxxxxxxxxx >>> http://lists.linuxaudio.org/listinfo/linux-audio-user _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
