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(a)linuxaudiosystems.com> 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(a)gmail.com> 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-som… >> Sent from the linux-audio-user mailing list archive at Nabble.com. >> _______________________________________________ >> Linux-audio-user mailing list >> Linux-audio-user(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-user

On Mon, Oct 5, 2015 at 8:25 AM, Ben Burdette &lt;bburdette(a)gmail.com <mailto:bburdette@gmail.com>> wrote: No one ever uses that portaudio mode in linux in the supercollider world, so its something of a surprise that it works at all. This quote alone suggests you may be overstating the difficulty of getting a working JACK system up and running with the latencies you require. If JACK were as bad as you maintain, surely more people would be using the alternative? I'd thoroughly recommend you spend the time you will spend trying to get the portaudio backend running the way you want and use that time instead to learn how to set up and use JACK on your platform. In my experience, once JACK is set up and running, it is as hassle free as any other direct interface, but with the added bonus of future flexibility if required...

From systemd jack mostly starts without xruns, if I 'sleep 30' first.

I think most people aren't running jack without a gui and on an arm computer. In that situation debian, for instance, has its dbus permissions completely hosed by default, from the standpoint of jack anyway.

Jack, while no doubt powerful in a studio situation, is for me a needless complication which has produced lots of sysadmin headaches and no benefits.

On 05.10.2015 01:25, Ben Burdette wrote: Have you tried with the mainline kernel, if you should be running a 'special' one instead? bananapi: sudo pacman -S linux-armv7 I have an Olinuxino-LIME2 running ArchLinux with linux-armv7, it has the same SOC (Allwinner A20) as the bananapi, iirc, and aplay only shows my usb card. lime2: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: MK2 [Traktor Audio 2 MK2], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 P.s. the mainline kernel does not ship with GPU acceleration and some other drivers that may be vital to your application... P.p.s: I'd recommend to use JACK1 instead of JACK2 on embedded platforms.

I've ordered an i2c audio device, will be curious to see if that makes for better latency than USB, but it probably won't arrive for a few weeks. From what I understand it should be a good bit faster.

On 10/06/2015 01:02 AM, Jeremy Jongepier wrote: Is that the buffering period you pass to jack? If so that would be 23.5ms (1024/44100) which would be a huge gain for me.

On 10/05/2015 01:25 AM, Ben Burdette wrote: JACK does not add latency. It does add some overhead, Jack2 some more than Jack1, and especially on small ARM dev boards like the bananapi. This overhead could get in the way of achieving the lowest latency possible compared to using plain ALSA. So if you're using an ARM board to output sound from a single application you might be better off using plain ALSA. Jeremy _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

On 05.10.2015 15:40, Paul Davis wrote: I wouldn't say that. The main benefit of JACK2 (at least for me) is SMP, which also leads to click-less connections. JACK2 also has "switch master", which allows to change JACK configurations on the fly without restarting the server. _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

Actually, this is still wrong (as was my comment). JACK1 adds no latency, and a very small amount of overhead. JACK2 run in its default mode adds latency, and a very small amount of overhead. JACK2 run in sync mode discards almost every benefit of using JACK2, adds no latency and a very small amount of overhead. I tend to forget this difference between JACK1 and JACK2. On Mon, Oct 5, 2015 at 5:45 AM, Jeremy Jongepier &lt;jeremy(a)autostatic.com&gt; wrote: _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

According to the article linked below, there is some kind of problem with usb devices, which is what I have, adding an extra period or 24ms, whichever is smaller.

On 10/04/2015 08:57 PM, ansible wrote: The audio codec drivers seem to be built-in and not dynamically loadable for your kernel. So any settings in /etc/modprobe won't have any effect. Which kernel are you using? What is the output of uname -a? Jeremy

On 04.10.2015 20:57, ansible wrote: Hi, you might also try to point scsynth (if that's the still the name of the supercollider synth server executable) to a different alsa device. What does man scsynth or scsynth --help or scsynth -h print? Flo