Question to sophisticated alsa developer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

I currently test alsa playback on AVR32 board with atmel's abdac driver.
My environment is 2.6.30.4 customized kernel (customization for my own
board), rootfs and toolchain made of customized buildroot from atmel. I
use alsa-lib 1.0.20 with patch [1] applied and alsa-utils with patch [2]
applied. The alsa code does compile and work fine (aside from my problem
described some lines later).

My test case is a sine wave file with 440Hz tone, samplerate is 17089
(cause of samplerate abdac driver offers and to avoid resampling in
alsa-lib) playing with aplay. This works fine, I see a 440Hz sine wave
on my oscilloscope and there is no effect as described later on.

My problem is when I'm enabling dmix layer to run concurrent aplay
processes I always get a click at the end of my last played sine wave
file. My Oscilloscope shows me that there is sometimes a short part of a
single or somtimes multiple sine period(s) moved down (or up) to mid
value (I can supply a screenshot of oscilloscope, if this description is
not clear enough). Mostly this effect is about 500 us long. The sine
wave is missing the information at this position, it is no delay of the
analog value at this position. If I overlay a correct sine wave the
following part after the problematic position matches exactly the
overlayed sine wave.
I investigated that this problem always occur somewhere at the end of
dmix. When I play a long "null" sample and start repeated play of my
short sine wave sample the effect is not there while the null sample is
playing. After ending of null sample the described effect appears
instantly on each end of my repeated test sample.

Here is my asound.conf to enable dmix layer for alsa:

---8<---
pcm.!default {
        type plug
        slave.pcm "dmixer"
}

ctl.mixer0 {
        type hw
        card 0
}

pcm.!plughw {
        type plug
        slave.pcm "dmixer"
}

pcm.dmixer {
        type dmix
        ipc_key 1024
        slave {
                pcm "hw:0"
                format S16_BE
                rate 17089
        }
        bindings {
                0 0
                1 1
        }
        slowptr	false
}

ctl.dmixer {
        type hw
        card 0
}
--->8---

Maybe there is already a bloomer in.

I have tried to change slowptr stuff in pcm.dmixer without any effect to
my problem. I also tried to change buffer sizes in dmixer's slave but
these changes had no effect.

I also tried some changes in kernel driver for ABDAC. I played a bit
with periods_min and period_bytes_min without effect to my problem. The
buffer_size in "Direct Stream Mixing PCM" is fixed to the value in
"hw:0". But if I double the periods_min in Kernel (default: 6
periods_min, 64 periods_max) for "hw:0" the maximum value for
buffer_size in "Direct Stream Mixing PCM" is fixed to 8192. The "Route
conversion" layer has always the buffer_size value of the next layer.
This is 8192 for doubled periods_min in kernel and dmix enabled and
12288 for doubled periods_min and dmix disabled. Any advice to this
"feature"?

Here is the output of aplay -v for dmix enabled:

---8<---
# aplay -v sin_440_17089_1sec.wav
Playing WAVE 'sin_440_17089_1sec.wav' : Signed 16 bit Little Endian,
Rate 17089 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S16_BE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 17089
  exact rate   : 17089 (17089/1)
  msbits       : 16
  buffer_size  : 8192
  period_size  : 1024
  period_time  : 59921
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 8192
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Slave: Direct Stream Mixing PCM
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_BE
  subformat    : STD
  channels     : 2
  rate         : 17089
  exact rate   : 17089 (17089/1)
  msbits       : 16
  buffer_size  : 8192
  period_size  : 1024
  period_time  : 59921
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 8192
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
Hardware PCM card 0 'Atmel ABDAC' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_BE
  subformat    : STD
  channels     : 2
  rate         : 17089
  exact rate   : 17089 (17089/1)
  msbits       : 16
  buffer_size  : 12288
  period_size  : 1024
  period_time  : 59921
  tstamp_mode  : ENABLE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 1
  stop_threshold   : 1610612736
  silence_threshold: 0
  silence_size : 1610612736
  boundary     : 1610612736
  appl_ptr     : 0
  hw_ptr       : 0
--->8---


And here the output of aplay -v without dmix:

---8<---
# aplay -v sin_440_17089_1sec.wav
Playing WAVE 'sin_440_17089_1sec.wav' : Signed 16 bit Little Endian,
Rate 17089 Hz, Mono
Plug PCM: Route conversion PCM (sformat=S16_BE)
  Transformation table:
    0 <- 0
    1 <- 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 17089
  exact rate   : 17089 (17089/1)
  msbits       : 16
  buffer_size  : 12288
  period_size  : 1024
  period_time  : 59921
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 12288
  stop_threshold   : 12288
  silence_threshold: 0
  silence_size : 0
  boundary     : 1610612736
Slave: Hardware PCM card 0 'Atmel ABDAC' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_BE
  subformat    : STD
  channels     : 2
  rate         : 17089
  exact rate   : 17089 (17089/1)
  msbits       : 16
  buffer_size  : 12288
  period_size  : 1024
  period_time  : 59921
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 12288
  stop_threshold   : 12288
  silence_threshold: 0
  silence_size : 0
  boundary     : 1610612736
  appl_ptr     : 0
  hw_ptr       : 0
--->8---

Well, currently I have no more ideas where to dig for my problem. I do
need a mixing layer to allow two or three concurrent aplay instances at
the same time but the output in this case is (atm) worse. Has anyone
some advice where to search for a solution to my problem. Or has anybody
some advice to use another feature of alsa to allow concurrent aplay
processes?

regards

Andreas Bießmann

[1]
http://git.buildroot.net/buildroot/tree/package/multimedia/alsa-lib/alsa-lib-1.0.18-avr32-bad-inline.patch

[2]
http://git.buildroot.net/buildroot/tree/package/multimedia/alsa-utils/alsa-utils-1.0.18-fix-intl-support.patch

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel


[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux