[alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support

Jyri Sarha jsarha at ti.com
Mon May 19 16:44:09 CEST 2014


On 05/17/2014 12:16 PM, Joachim Eastwood wrote:
> On 17 May 2014 10:51, Joachim  Eastwood <manabian at gmail.com> wrote:
>> On 14 May 2014 18:25, Joachim  Eastwood <manabian at gmail.com> wrote:
...
>>
>> I did some more testing over here.
>>
>> My HTPC (nVidia ION2 based) works good with speaker-test and all
>> channels are where they are suppose to be.
>>
>> On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
>> 1; done" and this had an interesting effect.
>> Most of the time FL (Front Left) is swapped with BL (Back Left) but
>> about every 10th time the sound comes out in the FL speaker... So
>> there something weird going on here. Same story for the right channel.
>>
>> I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
>> [ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
>> [ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
>> interface 58006000.encoder: -19
>>
>> But after replugging the HDMI connector a couple of times it starts to work.
>>

That is weird I can not reproduce this problem. I rebooted my panda 
several times and the audio device was always there. Could it be that 
the connector is in DVI mode or something?

>> I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
>
> On the 3.4 Variscite kernel:
> Linux version 3.4.0-1489-omap4 (uri at pluto) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10
> IDT 2013
> git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git +
> Variscite vendor patches
>
> Both speaker-test -c 4 and -c 8 works. All channels are where they are
> suppose to be.
>
> Hot plugging is broken, though. So the HDMI must be connected on boot,
> but that might be the Variscite board setup.
>

I checked the ubuntu branch implementation and found that it is quite 
different in many places, but the one place that affects the i2s channel 
mapping to HDMI looks exactly the same. So there must be a bug some 
where else and there is no point trying to fix it by changing the 
mapping (it would be impossible anyway). I'll compare the 
implementations further when I have time.

Thanks for your testing. Now I at least now where the bug is not.

Best regards,
Jyri


More information about the Alsa-devel mailing list