[alsa-devel] twl4030 and Puredata/jack
Ok,
Let me start off that I know very little about audio and drivers.
Recently I started looking in to running Puredata and possibly jack on the Pandora handheld. However I ran in to a number of problems getting these to interface with alsa. I should note that on the pandora we don't have too up to date versions of alsa and kernel so perhaps these are already resolved. In SL4P (slackware for pandora) I have:
ALSA: 1.0.24 Kernel: 3.2.30
I will paste a couple of use-cases and their corresponding dmesg output:
When I run ~$ pd -alsa I get:
snd_pcm_hw_params (input): Invalid argument snd_pcm_hw_params (output): Invalid argument
and: [201429.385345] omap_mcbsp_dai_hw_params: not enough bandwidth for desired rate and channels [201429.385375] asoc: interface omap-mcbsp-dai.1 hw params failed
With 'jackd -d alsa -S' (need s16_le):
loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|16bit control device hw:0 configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 16bit little-endian ALSA: use 2 periods for capture ALSA: cannot set hardware parameters for capture ALSA: cannot configure capture channel
cannot load driver module alsa
and: [201746.759857] asoc: can't set codec twl4030-hifi hw params
The pandora kernel-dev explained that the hardware can only handle stereo streams. However someone in #jack explains it as the following: "This typically means that the ALSA driver is incomplete or buggy when used the way JACK does (poll+mmap) vs. the way aplay does (blocking read+write). So things that do stuff the "aplay way" will work; things that do stuff the JACK way will not work."
I hope someone can shed some light on this and perhaps give some ideas to how to get this working.
cheers, alexander
On 03/08/2013 07:31 AM, Anders Alex wrote:
I will paste a couple of use-cases and their corresponding dmesg output:
When I run ~$ pd -alsa I get:
snd_pcm_hw_params (input): Invalid argument snd_pcm_hw_params (output): Invalid argument
and: [201429.385345] omap_mcbsp_dai_hw_params: not enough bandwidth for desired rate and channels [201429.385375] asoc: interface omap-mcbsp-dai.1 hw params failed
Strange. In kernel 3.2, omap-mcbsp-dai.1 (McBSP1) is used for the codec. But in the mainline it's omap-mcbsp-dai.2.
So the question is... how is the board wired? And does your kernel match the board?
With 'jackd -d alsa -S' (need s16_le):
loading driver .. creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|16bit control device hw:0 configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods ALSA: final selected sample format for capture: 16bit little-endian ALSA: use 2 periods for capture ALSA: cannot set hardware parameters for capture ALSA: cannot configure capture channel
Looking at the source, it looks like hw:0,0 has no capture port. Try adding the -P parameter to jackd. Playback only.
Also, post the output of:
$ cat /proc/asound/devices
-gabriel
On Sat, Mar 9, 2013 at 9:21 PM, Gabriel M. Beddingfield gabrbedd@gmail.comwrote:
Strange. In kernel 3.2, omap-mcbsp-dai.1 (McBSP1) is used for the codec. But in the mainline it's omap-mcbsp-dai.2.
So the question is... how is the board wired? And does your kernel match the board?
1) no idea 2) it should, yes.
Looking at the source, it looks like hw:0,0 has no capture port. Try adding the -P parameter to jackd. Playback only.
Hmm, when I do that I get:
[419034.693756] Alignment trap: not handling instruction edc46a06 at [<4022ce2c>] [419034.693878] Unhandled fault: alignment exception (0x801) at 0x4019e1e6
In dmesg. Apparently this is/was a known issue on jack2 and has been fixed there. No idea about jack1 (which I'm currently running). Will try to compile latest jack2 and report back on this.
Also, post the output of:
$ cat /proc/asound/devices
$ cat /proc/asound/devices 0: [ 0] : control 1: : sequencer 16: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 24: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 33: : time
-gabriel
On 03/11/2013 02:42 AM, Anders Alex wrote:
On Sat, Mar 9, 2013 at 9:21 PM, Gabriel M. Beddingfield gabrbedd@gmail.comwrote:
Strange. In kernel 3.2, omap-mcbsp-dai.1 (McBSP1) is used for the codec. But in the mainline it's omap-mcbsp-dai.2.
So the question is... how is the board wired? And does your kernel match the board?
- no idea 2) it should, yes.
McBSP2 is connected to PCM1773 for playback McBSP4 is connected to TWL4030 for capture
Both codec is slave, but the CLKS of McBSP is connected to TWL4030's CLKS out 256fs.
Since both PCM is hooked with the twl4030 codec driver, only stereo stream is supported because the twl4030 does not support mono on the HiFi DAI (it supports stereo or four channel). They needed to do this so when they do playback through the PCM1773 they need to power on the twl4030 codec and receive the 256fs from it.
Gražvydas Ignotas can correct me if I'm mistaken...
Looking at the source, it looks like hw:0,0 has no capture port. Try adding the -P parameter to jackd. Playback only.
Hmm, when I do that I get:
[419034.693756] Alignment trap: not handling instruction edc46a06 at [<4022ce2c>] [419034.693878] Unhandled fault: alignment exception (0x801) at 0x4019e1e6
In dmesg. Apparently this is/was a known issue on jack2 and has been fixed there. No idea about jack1 (which I'm currently running). Will try to compile latest jack2 and report back on this.
Also, post the output of:
$ cat /proc/asound/devices
$ cat /proc/asound/devices 0: [ 0] : control 1: : sequencer 16: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 24: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 33: : time
-gabriel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Mon, Mar 11, 2013 at 12:42 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 03/11/2013 02:42 AM, Anders Alex wrote:
On Sat, Mar 9, 2013 at 9:21 PM, Gabriel M. Beddingfield gabrbedd@gmail.comwrote:
Strange. In kernel 3.2, omap-mcbsp-dai.1 (McBSP1) is used for the codec. But in the mainline it's omap-mcbsp-dai.2.
So the question is... how is the board wired? And does your kernel match the board?
- no idea 2) it should, yes.
McBSP2 is connected to PCM1773 for playback McBSP4 is connected to TWL4030 for capture
Both codec is slave, but the CLKS of McBSP is connected to TWL4030's CLKS out 256fs.
That's right, the difference is because the dai numbering has changed in commit 45656b44 (used to be ...-dai.1 / -dai.3 for McBSP2/McBSP4 and is now ...-dai.2 and -dai.4).
On 03/11/2013 02:45 PM, Peter Ujfalusi wrote:
On 03/08/2013 04:31 PM, Anders Alex wrote:
With 'jackd -d alsa -S' (need s16_le):
I'm not really a jack user, but can you try: jackd -d alsa -o 2 -i 2 -S -C hw:0,1 -P hw:0,0
So you tell jack to play on hw:0,0 record on hw:0,1 use stereo for both.
I have tried jack on my BeagleBoard (using twl4030 codec):
jackd -d alsa -o 2 -i 2 -S -C hw:0,0 -P hw:0,0 mplayer -ao jack media/music/nin-echoplex.flac
It works fine.
On Mon, Mar 11, 2013 at 6:31 PM, Peter Ujfalusi peter.ujfalusi@ti.comwrote:
On 03/11/2013 02:45 PM, Peter Ujfalusi wrote:
On 03/08/2013 04:31 PM, Anders Alex wrote:
With 'jackd -d alsa -S' (need s16_le):
I'm not really a jack user, but can you try: jackd -d alsa -o 2 -i 2 -S -C hw:0,1 -P hw:0,0
So you tell jack to play on hw:0,0 record on hw:0,1 use stereo for both.
I have tried jack on my BeagleBoard (using twl4030 codec):
jackd -d alsa -o 2 -i 2 -S -C hw:0,0 -P hw:0,0 mplayer -ao jack media/music/nin-echoplex.flac
It works fine.
With jack1 I was still having problems. Also occasionally the known alignment-trap issue. I now built jack2 from latest git and it works! (with your suggested 'jackd -d alsa -o 2 -i 2 -S -C hw:0,1 -P hw:0,0' to specify the devices) Also built vanilla Puredata with build-optimizations for pandora (and enabled jack and disabled direct alsa) and this now works as well!
-- Péter
participants (4)
-
Anders Alex -
Gabriel M. Beddingfield -
Grazvydas Ignotas -
Peter Ujfalusi