Problems with audio recording using Duovero and 4.x kernels

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems with audio recording using Duovero and 4.x kernels

Scott Ellis
I am trying to record some sound files from a USB microphone
on a Duovero system and getting bad results from 4.1 and 4.4
kernels while 3.18 kernels are okay.

The userland, bootloader, hardware, etc... are identical, only the
kernel is changing. The device tree is an unmodified omap4-duovero-parlor.dtb.

I'm testing with linux-stable 3.18.41, 4.1.32, 4.4.20 kernels.

I'm showing results using a USB camera microphone, but customer
sees the same with a dedicated USB microphone.

The available capture devices appear the same on all systems

root@duo:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: DuoVero [DuoVero], device 0: TWL6040 twl6040-legacy-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: U0x46d0x81d [USB Device 0x46d:0x81d], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


A simple test with arecord demonstrates the problem.

root@duo:~# uname -a
Linux duo 3.18.41-jumpnow #1 SMP Mon Sep 12 14:53:33 EDT 2016 armv7l armv7l armv7l GNU/Linux

root@duo:~# arecord -v -f dat -D hw:1,0 -c 1 -d 10 test318.wav
Recording WAVE 'test318.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hardware PCM card 1 'USB Device 0x46d:0x81d' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 1572864000
  appl_ptr     : 0
  hw_ptr       : 0

The resulting wav file played back on another machine sounds good.
The command takes 10 seconds to complete as expected. There are
no errors on the syslog.


On a 4.1 system (4.4 is similar) the same command takes 30 seconds to
complete.

root@duo:~# uname -a
Linux duo 4.1.32-jumpnow #1 SMP Mon Sep 12 15:32:25 EDT 2016 armv7l armv7l armv7l GNU/Linux

root@duo:~# arecord -v -f dat -D hw:1,0 -c 1 -d 10 test41.wav
Recording WAVE 'test41.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hardware PCM card 1 'USB Device 0x46d:0x81d' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 1572864000
  appl_ptr     : 0
  hw_ptr       : 0

Kernel errors are seen in the syslog while arecord is running

[ 1256.326354] retire_capture_urb: 3591 callbacks suppressed
[ 1261.346343] retire_capture_urb: 3554 callbacks suppressed
[ 1266.396301] retire_capture_urb: 3492 callbacks suppressed
[ 1271.406616] retire_capture_urb: 3557 callbacks suppressed
[ 1276.526245] retire_capture_urb: 2980 callbacks suppressed
[ 1281.545745] retire_capture_urb: 3617 callbacks suppressed
[ 1287.077697] retire_capture_urb: 942 callbacks suppressed
[ 1292.116088] retire_capture_urb: 3500 callbacks suppressed
[ 1297.126342] retire_capture_urb: 3539 callbacks suppressed
[ 1302.208953] retire_capture_urb: 3505 callbacks suppressed
[ 1307.287689] retire_capture_urb: 3523 callbacks suppressed
[ 1312.326019] retire_capture_urb: 3093 callbacks suppressed
[ 1317.435516] retire_capture_urb: 3346 callbacks suppressed


When the resulting wav file is played back on another machine
it is sped up by what appears to be 3 times normal speed.
(Changing playback in Audacity by a factor of 0.33)

The resulting wave files are the same length on either system,
960,044 bytes.

Audacity says both files contain 10 seconds of audio.

There are occasionally short periods in the 4.1 generated file
where the sound appears to be at the correct speed.

Any ideas?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with audio recording using Duovero and 4.x kernels

Akram Hameed
Hi Scott,

I'm not quite sure what might be causing this issue, but you might have some luck on alsa-user or alsa-devel mailing lists. I got a fairly helpful response on there after a bit of patience and prodding the right person. You'll probably have to find a few more details about your USB mic though so the appropriate people know to pay attention. I note that printk spam was reported with regards to USB mics a while ago. Report in launchpad here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319457

I also found this ancient, but interesting one regarding connecting the USB device via a hub rather than to the controller itself: http://ryannull.com/blog/2013/07/02/issues-with-usb-microphone-linux-retire_capture_urb-callback-suppressed/

Cheers,

Akram

On Tue, Sep 13, 2016 at 8:31 PM, Scott Ellis <[hidden email]> wrote:
I am trying to record some sound files from a USB microphone
on a Duovero system and getting bad results from 4.1 and 4.4
kernels while 3.18 kernels are okay.

The userland, bootloader, hardware, etc... are identical, only the
kernel is changing. The device tree is an unmodified
omap4-duovero-parlor.dtb.

I'm testing with linux-stable 3.18.41, 4.1.32, 4.4.20 kernels.

I'm showing results using a USB camera microphone, but customer
sees the same with a dedicated USB microphone.

The available capture devices appear the same on all systems

root@duo:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: DuoVero [DuoVero], device 0: TWL6040 twl6040-legacy-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: U0x46d0x81d [USB Device 0x46d:0x81d], device 0: USB Audio [USB
Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


A simple test with arecord demonstrates the problem.

root@duo:~# uname -a
Linux duo 3.18.41-jumpnow #1 SMP Mon Sep 12 14:53:33 EDT 2016 armv7l armv7l
armv7l GNU/Linux

root@duo:~# arecord -v -f dat -D hw:1,0 -c 1 -d 10 test318.wav
Recording WAVE 'test318.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Mono
Hardware PCM card 1 'USB Device 0x46d:0x81d' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 1572864000
  appl_ptr     : 0
  hw_ptr       : 0

The resulting wav file played back on another machine sounds good.
The command takes 10 seconds to complete as expected. There are
no errors on the syslog.


On a 4.1 system (4.4 is similar) the same command takes 30 seconds to
complete.

root@duo:~# uname -a
Linux duo 4.1.32-jumpnow #1 SMP Mon Sep 12 15:32:25 EDT 2016 armv7l armv7l
armv7l GNU/Linux

root@duo:~# arecord -v -f dat -D hw:1,0 -c 1 -d 10 test41.wav
Recording WAVE 'test41.wav' : Signed 16 bit Little Endian, Rate 48000 Hz,
Mono
Hardware PCM card 1 'USB Device 0x46d:0x81d' device 0 subdevice 0
Its setup is:
  stream       : CAPTURE
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 1572864000
  appl_ptr     : 0
  hw_ptr       : 0

Kernel errors are seen in the syslog while arecord is running

[ 1256.326354] retire_capture_urb: 3591 callbacks suppressed
[ 1261.346343] retire_capture_urb: 3554 callbacks suppressed
[ 1266.396301] retire_capture_urb: 3492 callbacks suppressed
[ 1271.406616] retire_capture_urb: 3557 callbacks suppressed
[ 1276.526245] retire_capture_urb: 2980 callbacks suppressed
[ 1281.545745] retire_capture_urb: 3617 callbacks suppressed
[ 1287.077697] retire_capture_urb: 942 callbacks suppressed
[ 1292.116088] retire_capture_urb: 3500 callbacks suppressed
[ 1297.126342] retire_capture_urb: 3539 callbacks suppressed
[ 1302.208953] retire_capture_urb: 3505 callbacks suppressed
[ 1307.287689] retire_capture_urb: 3523 callbacks suppressed
[ 1312.326019] retire_capture_urb: 3093 callbacks suppressed
[ 1317.435516] retire_capture_urb: 3346 callbacks suppressed


When the resulting wav file is played back on another machine
it is sped up by what appears to be 3 times normal speed.
(Changing playback in Audacity by a factor of 0.33)

The resulting wave files are the same length on either system,
960,044 bytes.

Audacity says both files contain 10 seconds of audio.

There are occasionally short periods in the 4.1 generated file
where the sound appears to be at the correct speed.

Any ideas?




--
View this message in context: http://gumstix.8.x6.nabble.com/Problems-with-audio-recording-using-Duovero-and-4-x-kernels-tp4971076.html
Sent from the Gumstix mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------

_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with audio recording using Duovero and 4.x kernels

Scott Ellis
Bisecting between a working linux-stable-4.0 and non-working linux-stable-4.1
this is the commit that is breaks USB audio recording on the Duovero


commit 7136d457f365ecc93ddffcdd42ab49a8473f260b
Author: Marc Zyngier <marc.zyngier@arm.com>
Date:   Wed Mar 11 15:43:49 2015 +0000

    ARM: omap: convert wakeupgen to stacked domains

    OMAP4/5 has been (ab)using the gic_arch_extn to provide
    wakeup from suspend, and it makes a lot of sense to convert
    this code to use stacked domains instead.

    This patch does just this, updating the DT files to actually
    reflect what the HW provides.

    BIG FAT WARNING: because the DTs were so far lying by not
    exposing the WUGEN HW block, kernels with this patch applied
    won't have any suspend-resume facility when booted with old DTs,
    and old kernels with updated DTs won't even boot.

    On a platform with this patch applied, the system looks like
    this:
    ...


There is a related 'fix' to that commit also in the 4.0 - 4.1 timeframe


commit 63059a272398ef5dc1bd7065a036e8b6e82d1af7
Author: Grygorii Strashko <grygorii.strashko@ti.com>
Date:   Fri Aug 14 15:20:28 2015 +0300

    ARM: OMAP: wakeupgen: Restore the irq_set_type() mechanism

    The conversion of the wakeupgen irqchip to hierarchical irq domains
    failed to provide a mechanism to properly set the trigger type of an
    interrupt.

    The wakeupgen irq chip itself has no mechanism and therefor no
    irq_set_type() callback. The code before the conversion relayed the
    trigger configuration directly to the underlying GIC.

    Restore the correct behaviour by setting the wakeupgen irq_set_type
    callback to irq_chip_set_type_parent(). This propagates the
    set_trigger() call to the underlying GIC irqchip.

    [ tglx: Massaged changelog ]

    Fixes: 7136d457f365 ('ARM: omap: convert wakeupgen to stacked domains')
    ...

But I've tested all the way up through 4.7.3 kernels and USB audio recording
is still broken on the Duovero.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with audio recording using Duovero and 4.x kernels

Scott Ellis
It looks to me like the original 7136d457f commit was incomplete.

The following patch fixes the problem for me on 4.4 kernels.

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5a206c1..8a5628c 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -844,14 +844,12 @@
                        usbhsohci: ohci@4a064800 {
                                compatible = "ti,ohci-omap3";
                                reg = <0x4a064800 0x400>;
-                               interrupt-parent = <&gic>;
                                interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
                        };

                        usbhsehci: ehci@4a064c00 {
                                compatible = "ti,ehci-omap";
                                reg = <0x4a064c00 0x400>;
-                               interrupt-parent = <&gic>;
                                interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
                        };
                };

A similar patch also fixes 4.1

You can find a patch for a Yocto linux-stable-4.4 recipe here

  https://github.com/jumpnow/meta-duovero/blob/krogoth/recipes-kernel/linux/linux-stable-4.4/

for linux-stable-4.1

  https://github.com/jumpnow/meta-duovero/tree/krogoth/recipes-kernel/linux/linux-stable-4.1
Loading...