I have a BeagleBone Black running a patched Linux 3.16.1 kernel which
includes the Botic Audio Driver (http://bbb.ieero.com/) and a dummy codec
configured to support both capture and playback streams. The mcasp0 is
providing the clock (e.g. generated internally) and I have configured two
McASP serializers ( 0-1) to support the transmit of two I2S streams (4
32-bit slots). The third serializer is configured for RX of a single I2S
stream (e.g. two 32-bit slots). The fourth serializer on mcasp0 is inactive
(unused). All serializer pins of mcasp0 are brought out through the P9
header via modifications to the device tree.
For my application, I need to support simultaneous capture/playback from
the single mcasp0. Both streams have identical sample rates (e.g. the
streams are symmetric). So I have one application (aplay) that plays a
stream and a second (arecord) that records from the same ALSA PCM stream
using the asym/dsnoop/dmix, plugins i.e.
/etc/asound.rc
===========
pcm.dmix_48000{
type dmix
ipc_key 5678293
ipc_key_add_uid yes
slave {
pcm "hw:0,0"
rate 48000
format S16_LE
channels 4
}
}
pcm.dsnoop_48000{
type dsnoop
ipc_key 5778293
ipc_key_add_uid yes
slave {
pcm "hw:0,0"
rate 48000
format S16_LE
}
}
pcm.asymed {
type asym
playback.pcm "dmix_48000"
capture.pcm "dsnoop_48000"
}
pcm.Stereo32 {
type plug
slave {
pcm "asymed"
}
ttable.1.0 0
ttable.1.1 1
ttable.0.2 0
ttable.0.3 1
}
So, for playback I run aplay with the following arguments:
aplay -D Stereo32 -f dat -r 48000 -c 2 /dev/urandom
This plays fine and I hear what I expect.
While playback is running I start a 10 second capture:
arecord -D asymed -f dat -r 48000 -c 2 -d 10 /temp/audio.wav
As soon as capture starts playback ceases. The captured audio is valid and
correct (I hear what I expected to capture). The playback does *not* resume
until I stop 'aplay' and re-run the aplay command.
I know TI claims their davinci-mcasp.c driver supports simultaneous
capture/playback (full duplex operation) but that's not what I've been
experiencing. Looking at the driver code I *cannot* see where they check to
see if there is an (already active stream) before configuring either the TX
or RX side of the mcasp. Some of the registers they're configuring are
global to both TX/RX and the associated serializers. It appears configuring
for playback or capture clobbers whatever is the current activity. So my
question becomes - has anyone successfully been able to simultaneously
capture/playback using the same mcasp? If so, how was this verified? After
liberally sprinkling the davinci-mcasp.c driver with printk's I am
concerned the driver does not really address this use-case adequately. Can
someone either confirm my observation or provide an explanation otherwise?
Thanks . . .
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
