[Arm-netbook] A10 and all things audio

Mark Wilczynski mark_wilczynski at hotmail.com
Fri Jul 13 22:04:38 BST 2012


> Date: Fri, 13 Jul 2012 11:44:36 +0200 
> From: p.steenbergen at j1nx.nl 
> To: arm-netbook at lists.phcomp.co.uk 
> Subject: Re: [Arm-netbook] A10 and all things audio 
>  
>  
> Actually, while cycling home, I think that this is normal. The PCM streams 
> will then have the 5.1 encoded in them, or something along those lines. I 
> think we need to look at the userland libraries, which we do not have 
> sources for? 
>  
> But that would mean ALSA (under linux), which again you can get the  
> sources for if you want. 
>  
> But why do you think that? 
>  

The 2 channel limit thing is perfectly normal.  It's because spdif only has enough bandwidth to carry 2 channels of uncompressed audio.  But you can stuff way more than 2 channels into that bandwidth when it is compressed (like AC3 or DTS).  You encapsulate the compressed audio frames inside the 2-channel PCM stream.  As long as the hardware does not run the PCM data into some kind of mixer (which would mangle it), it should work fine for non-hd audio bitstreaming.  I don't have any android or linux audio experience, but on Windows you have to tell the system that your PCM data contains compressed audio so that it doesn't mess with it.  I think Linux is similar.  I would look at some open source media player for Linux (vlc, mplayer, etc.) to see how they handle it.
BTW, based on the a10 data sheets that I remember seeing somewhere, the HDMI is supposed to support up to 8 PCM channels.  That means enough bandwidth for any HD audio format.  But the HD-audio encapsulation is more complicated than simple spdif.  I would check Linux XBMC for how they handle HD-audio bitstreaming.  I'm not sure you'll be able to get any of this working on Android without major hacking.
But just to be clear - you had no audio problems sending stereo PCM to your TV directly over HDMI correct?  Only HDMI AVR had issues?  If so, that at least rules out some kind of dma ring-buffer under/over flow of the audio data.  It would mean either some kind of EDID issue or a timing problem with the AVR.  I would solve that first before trying to mess with surround audio bitstreaming. 		 	   		  


More information about the arm-netbook mailing list