Re: [LAU] make alsa device hw:1,0 be hw:0,0 somehow

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@email-addr-hidden> 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@email-addr-hidden> 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@email-addr-hidden ~]$ 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@email-addr-hidden ~]$
>>> ```
>>>
>>> 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@email-addr-hidden ~]$ 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@email-addr-hidden ~]$ cat /etc/modprobe.d/alsa-base.conf
>>> options snd_usb_audio index=0
>>> options sunxicodec index=1
>>> [bananapi@email-addr-hidden ~]$
>>> ```
>>>
>>> After creating that file and rebooting aplay just returns this.
>>>
>>> ```
>>> [bananapi@email-addr-hidden ~]$ 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@email-addr-hidden ~]$
>>> ```
>>>
>>> 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@email-addr-hidden
>>> http://lists.linuxaudio.org/listinfo/linux-audio-user

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Mon Oct 5 04:15:03 2015