Arch Linux

drwho9437

Member

Registered: 2014-03-20

Posts: 5

Priority of audio driver/ALSA etc

I have been trying my best to figure this out by searching and reading but I am pretty lost now and would appreciate some help.

I have been working on a project using Beaglebone Black. My system is pretty much configured as the base ARM Arch system.

I am using ALSA and this module: http://bbb.ieero.com/ for the I2S output.

What I need help with is understanding what would dictate the system's ability to keep the FIFO full for the I2S stream. I have been trying to figure out how to assess the IRQ or thread priority of all the parts of the system that are between an application like say aplay and the actual data coming out serialized.

I honestly haven't been able to even figure out the PID for the audio driver. Similarly cat /proc/interrupts is pretty opaque. I will list it at the end of the post with my take on what each line is.

How can I determine the priority of the kernel module I have inserted to deal with audio and any other parts of the system that are not normal user space processes that take my original audio file and turn it into serial data?

Here is what is in /proc/interrupts (happy to provide any data people need to help me understand this problem):

  7:          1      INTC  tps65217 -> I think this is power mangement
12:       2991      INTC  edma -> DMA for the SoC probably so this is part of giving the FIFO what it needs from the user space application
14:          0      INTC  edma_error -> errors from DMA
18:          0      INTC  musb-hdrc.0.auto -> USB
19:          1      INTC  musb-hdrc.1.auto -> USB
28:        750      INTC  mmc1 -> I guess this services the "hard disk" equivalent on this system maybe this is the eMMC?
30:         96      INTC  4819c000.i2c -> I presume an I2C controller
36:          0      INTC  tilcdc -> ?
40:          0      INTC  4a100000.ethernet
41:        191      INTC  4a100000.ethernet
42:         64      INTC  4a100000.ethernet
43:          0      INTC  4a100000.ethernet
64:       9465      INTC  mmc0 -> I guess this services the "hard disk" equivalent on this system maybe this is the SD card?
67:       8650      INTC  gp_timer -> general purpose timer, the audio system certain needs a timer to provide data if I read this correct this isn't a very high priority
It is somewhat unclear what timer the audio driver uses to know when to service add data to the FIFO (or it could look at a flag I guess also) /proc/asound/timer is:

G0: system timer : 1953.125us (10000000 ticks)
G3: HR timer : 0.001us (1000000000 ticks)
P0-0-0: PCM playback 0-0-0 : SLAVE

70:        274      INTC  44e0b000.i2c -> again an I2C controller?
72:        478      INTC  OMAP UART0 -> presumably the first UART on the SoC
75:          0      INTC  rtc0 -> real time clock
76:          0      INTC  rtc0 -> real time clock
109:          0      INTC  53100000.sham -? ???
134:          0      GPIO  mmc0
IPI0:          0  CPU wakeup interrupts
IPI1:          0  Timer broadcast interrupts
IPI2:          0  Rescheduling interrupts
IPI3:          0  Function call interrupts
IPI4:          0  Single function call interrupts
IPI5:          0  CPU stop interrupts
Err:          0

brebs

Member

Registered: 2007-04-03

Posts: 3,742

Re: Priority of audio driver/ALSA etc

Try threadirqs kernel option (specified in your bootloader), and set the audio IRQ priority.

drwho9437

Member

Registered: 2014-03-20

Posts: 5

Re: Priority of audio driver/ALSA etc

Do I have to recompile the kernel for that?

It doesn't seem like there are any sound IRQs

ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i "irq"
    3  TS      -  19   0 [ksoftirqd/0]
   20  FF     50  90   - [irq/70-44e0b000]
   24  FF     50  90   - [irq/7-tps65217]
   27  FF     50  90   - [irq/30-4819c000]
   59  FF     50  90   - [irq/134-mmc0]
  450  TS      -  19   0 grep -i irq

But perhaps that is because threadirq is not on?

drwho9437

Member

Registered: 2014-03-20

Posts: 5

Re: Priority of audio driver/ALSA etc

I added bootargs=threadirqs to my uBoot environmental vars but there are no processes that pgrep with snd in them