10 Dec
2013
10 Dec
'13
9:44 p.m.
Hello LAD, I'm working in company which is developing a guitar pedal board
which runs Linux (arch) and my task now is to make the kernel's usb audio
driver more appropriate to our sound card. I'm kinda lost in this since i
have a brief knowledge on usb protocol so I was hoping that you could give
me some directions on how can I optimize the driver latency wise, any tips?
Att,
Lucas
10 Dec
10 Dec
11:49 p.m.
On Wed, December 11, 2013 7:44 am, Lucas Takejame wrote:
Hello LAD, I'm working in company which is
developing a guitar pedal board
which runs Linux (arch) and my task now is to make the kernel's usb audio
driver more appropriate to our sound card. I'm kinda lost in this since i
have a brief knowledge on usb protocol so I was hoping that you could give
me some directions on how can I optimize the driver latency wise, any
tips?
The ALSA USB Audio driver is already highly optimised. If you are seeing
specific issues the alsa-devel mailing list is a better place to discuss.
Or are you looking to optimise the kernel and operating system?
FYI, other LADers have been using usb devices with 64 frames per period
which provides less than 2ms round trip latency.
--
Patrick Shirkey
Boost Hardware Ltd
11 Dec
11 Dec
2:01 a.m.
On 12/10/2013 12:44 PM, Lucas Takejame wrote:
Hello LAD, I'm working in company which is
developing a guitar pedal
board which runs Linux (arch) and my task now is to make the kernel's
usb audio driver more appropriate to our sound card. I'm kinda lost in
this since i have a brief knowledge on usb protocol so I was hoping that
you could give me some directions on how can I optimize the driver
latency wise, any tips?
There's several folks here who do this, but your best bet is to look for
advice (or contractors) on the alsa-devel mailing list.[1]
One option is to implement a class-compliant USB Audio device. Then
your device will work out of the box with all operating systems.
If class-compliance doesn't suit your device... then look for examples
in the linux kernel in sound/usb where there's a few non-class-compliant
cards cards supported there.
In addition, check out these resources:
* Takashi Iwei's ALSA driver tutorial[2]. Concentrate on the
PCM interface portion of the document.
* Linux Device Drivers from O'Reilly media.[3]
-gabe
[1] http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[2] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/
[3] http://lwn.net/Kernel/LDD3/
8:55 a.m.
Lucas Takejame wrote:
my task now is to make the kernel's usb audio
driver more appropriate
to our sound card.
What specific problem do you have?
I was hoping that you could give me some directions on
how can I
optimize the driver latency wise, any tips?
For playback, you get lower latency by using a smaller buffer (which
also increases the chance of an underrun).
Regards,
Clemens
5:31 p.m.
We are already using a RT-kernel and I guess we already did everything we
could do on OS changes to achieve a better latency. My doubt is if I can
change anything on the snd-usb driver to make it specific to our sound
card, aiming an improve in latency, since our pedalboard (
http://portalmod.com/en/index.html) has this sound card fixed and we won't
need a generic driver to the usb connection. I'm gonna send an e-mail to
the alsa-devel ML, thanks for the advices!
2013/12/11 Clemens Ladisch <clemens(a)ladisch.de>
Lucas Takejame wrote:
--
Lucas Conejero Takejame
Engenharia Elétrica - ênfase em computação
Escola Politécnica - USP
my task now is to make the kernel's usb audio
driver more appropriate
to our sound card.
What specific problem do you have?
I was hoping that you could give me some
directions on how can I
optimize the driver latency wise, any tips?
For playback, you get lower latency by using a smaller buffer (which
also increases the chance of an underrun).
Regards,
Clemens
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
6:01 p.m.
On Wed, 2013-12-11 at 14:31 -0200, Lucas Takejame wrote:
We are already using a RT-kernel and I guess we
already did everything
we could do on OS changes to achieve a better latency. My doubt is if
I can change anything on the snd-usb driver to make it specific to our
sound card, aiming an improve in latency, since our pedalboard
(http://portalmod.com/en/index.html) has this sound card fixed and we
won't need a generic driver to the usb connection. I'm gonna send an
e-mail to the alsa-devel ML, thanks for the advices!
Linux audio user might be a better place to ask first. Since you're
using Arch, ArchAudio mailing list might be a good place too.
Get rid of as much as you can and avoid shared IRQs. If I only need my
RME card, sometimes I even disable the Envy24 MIDI interfaces.
Often I don't use this script, because it doesn't really improve issues
that much on my machine, but you never know and could try as much tuning
as possible.
Perhaps the links are still helpful, I don't know.
[rocketmouse@archlinux ~]$ cat /usr/local/sbin/tuning
#!/bin/bash
# /usr/local/sbin/tuning - Arch Linux
# 2013/Apr/05
### http://www.mythtv.org/wiki/PCI_Latency
### http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
### Bluetooth
#service bluetooth stop
### Network
#service network-manager stop
#service networking stop # does cause serious issues
#modprobe -r r8169 # Ethernet NIC driver
### TerraTec EWX 24/96
#modprobe -r snd_ice1712
### Others
modprobe -r firewire-ohci
modprobe -r firewire_core
#service cups stop
modprobe -r ppdev # parallel port
modprobe -r lp # printer
### Unbinding devices
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
### Log file
l="/var/log/tuning.log"
#echo "$ lspci -v " > $l
#lspci -v >> $l
#echo >> $l
echo "# service rtirq status " > $l
service rtirq status >> $l
echo "# grep 18: /proc/interrupts" >> $l
grep 18: /proc/interrupts >> $l
echo >> $l
echo -n $(date)" - "$(uname -r)" - " >> $l
cat /etc/issue >> $l
echo -e
"\n########################################################################\n" ;
cat $l
exit 0
8 p.m.
Thanks for your response Ralf, our Arch is pretty much dedicated to audio
already, we maintained only the necessary to work as a LV2 host (this
script wouldn't do much actually) and the IRQ's are not shared, we are
using different USB hubs to prioritize audio, I think we did what we could
without changing code lines already, this is why I was asking about the
drivers haha.
2013/12/11 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
On Wed, 2013-12-11 at 14:31 -0200, Lucas Takejame
wrote:
--
Lucas Conejero Takejame
Engenharia Elétrica - ênfase em computação
Escola Politécnica - USP
We are already using a RT-kernel and I guess we
already did everything
we could do on OS changes to achieve a better latency. My doubt is if
I can change anything on the snd-usb driver to make it specific to our
sound card, aiming an improve in latency, since our pedalboard
(http://portalmod.com/en/index.html) has this sound card fixed and we
won't need a generic driver to the usb connection. I'm gonna send an
e-mail to the alsa-devel ML, thanks for the advices!
Linux audio user might be a better place to ask first. Since you're
using Arch, ArchAudio mailing list might be a good place too.
Get rid of as much as you can and avoid shared IRQs. If I only need my
RME card, sometimes I even disable the Envy24 MIDI interfaces.
Often I don't use this script, because it doesn't really improve issues
that much on my machine, but you never know and could try as much tuning
as possible.
Perhaps the links are still helpful, I don't know.
[rocketmouse@archlinux ~]$ cat /usr/local/sbin/tuning
#!/bin/bash
# /usr/local/sbin/tuning - Arch Linux
# 2013/Apr/05
### http://www.mythtv.org/wiki/PCI_Latency
###
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat…
### Bluetooth
#service bluetooth stop
### Network
#service network-manager stop
#service networking stop # does cause serious issues
#modprobe -r r8169 # Ethernet NIC driver
### TerraTec EWX 24/96
#modprobe -r snd_ice1712
### Others
modprobe -r firewire-ohci
modprobe -r firewire_core
#service cups stop
modprobe -r ppdev # parallel port
modprobe -r lp # printer
### Unbinding devices
echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
### Log file
l="/var/log/tuning.log"
#echo "$ lspci -v " > $l
#lspci -v >> $l
#echo >> $l
echo "# service rtirq status " > $l
service rtirq status >> $l
echo "# grep 18: /proc/interrupts" >> $l
grep 18: /proc/interrupts >> $l
echo >> $l
echo -n $(date)" - "$(uname -r)" - " >> $l
cat /etc/issue >> $l
echo -e
"\n########################################################################\n"
; cat $l
exit 0
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
8:36 p.m.
On Wed, 2013-12-11 at 17:00 -0200, Lucas Takejame wrote:
Thanks for your response Ralf, our Arch is pretty much
dedicated to
audio already, we maintained only the necessary to work as a LV2 host
(this script wouldn't do much actually) and the IRQ's are not shared,
we are using different USB hubs to prioritize audio, I think we did
what we could without changing code lines already, this is why I was
asking about the drivers haha.
Sure, the script is for my machine, I only wanted to point out, that I
would test what happens if everything that is unneeded is removed. To
check if rtirq is ok, since after a linux-rt upgrade it could be broken,
but if you already cared about such things, I suspect there is nothing
you can do.
12 Dec
12 Dec
6:58 p.m.
Me too
2013/12/11 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
On Wed, 2013-12-11 at 17:00 -0200, Lucas Takejame
wrote:
--
Lucas Conejero Takejame
Engenharia Elétrica - ênfase em computação
Escola Politécnica - USP
Thanks for your response Ralf, our Arch is pretty
much dedicated to
audio already, we maintained only the necessary to work as a LV2 host
(this script wouldn't do much actually) and the IRQ's are not shared,
we are using different USB hubs to prioritize audio, I think we did
what we could without changing code lines already, this is why I was
asking about the drivers haha.
Sure, the script is for my machine, I only wanted to point out, that I
would test what happens if everything that is unneeded is removed. To
check if rtirq is ok, since after a linux-rt upgrade it could be broken,
but if you already cared about such things, I suspect there is nothing
you can do.
22 Dec
22 Dec
3:49 p.m.
Hi Lucas,
What are the problems that the supposed driver modification is meant to
solve?
Ciao,
Kaspar
3984
days inactive
3996
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Clemens Ladisch -
Gabriel M. Beddingfield -
Kaspar Emanuel -
Lucas Takejame -
Patrick Shirkey -
Ralf Mardorf