Audio Over AOA 2.0 (For Android Phones)

[jayjay]

I have been using the LUFA library to try out some of the new features of the AOA 2.0 protocol for my project.

The demo that is currently included with LUFA library only works with AOA 1.0, so I added all the new commands following this document: 

http://source.android.com/tech/accessories/aoap/aoa2.html

So the good news is I can easily put the phone into 0x2D02  (Audio mode), and can send HID commands to the phone  over AOA 2.0 which all works great!

Then I followed the Audio In host example to get me going with actually playing the audio on the AVR USB Key2 board (PWM Output).

This is where I get stuck, the phone does think an Audio device is connects so it routes the sound to USB, but all I get from the PWM output is static.

I had to comment out the Audio_Host_GetSetEndpointProperty(...) part since AOA 2.0 only supports 44100hz (Can I do this or does it do something other then set the frequency?) 

I always got the "Error Setting Audio Sampling Frequency". 

Secondly, how does the library handle mono vs stereo output? The example is mono and the phone is outputting stereo which cannot be changed. 

Is the difference simply reading one sample, vs reading two samples in the ISR?

Am I missing anything?

Any help would be much appreciated!

Thank You guys,

Jay

[jayjay]

So after spending some time trying to figure out what was wrong, I discovered that the Audio over the AOA 2.0 protocol enumerates with:

Endpoint:

 Size 384

 Address 129

 Type 1

 Banks 2

 Control 0

 Interface 1

 Enable Streaming 1

I read on a previous post from Dean that the largest supported bank size on an 8 bit AVR like the AT90USB1287 is

256 byte. So is there anyway to get around the 384 byte packet size without switching to better processor?

Jay

[jayjay]

I guess I should post one more thing, this is the ConfigDescriptorData that I get back from the Android Phone Running AOA 2.0 when it is in audio mode.

I have highlighted in red the endpoint which is being used. 

At 44,100Hz x 16 bit samples x 2 channels with a 1ms polling interval for the Isochronous Transfers type, 

the max buffer size should be between 176 - 180. 

So then why does the phone show 0x0180 (384)?

ConfigDescriptorData:

09 Size in bytes

02 Configuration Descriptor (0x02)

006E Total length in bytes of data returned (110) 

2 Number of Interfaces

1 Value to use as an argument to select this configuration

0 Index of String Descriptor describing this configuration

80  (10000000) 

FA  500 mAh

9 Size in bytes

4 Interface Descriptor (0x04)

0 Number of Interface (0)

0 Value used to select alternative setting

0 Number of Endpoints used for this interface

1 Class Code (Assigned by USB Org

1 Subclass Code (Assigned by USB Org)

0 Protocol Code (Assigned by USB Org)

0 Index of String Descriptor Describing this interface

A

24

1

0

1

28

0

2

0

1

C

24

2

1

1

2

0

2

3

0

0

0

9

24

3

3

1

1

2

2

0

9

24

6

2

1

2

0

0

0

9

4

1 Number of Interface

0 Value used to select alternative setting

0 Number of Endpoints used for this interface

1

2

0

0

9

4

1 Number of Interface

1 Value used to select alternative setting

1 Number of Endpoints used for this interface

1

2

0

0

7

24

1

1

1

1

0

B

24

2

1

2

2

10

1

44

AC

0

9

5 Endpoint Descriptor (0x05)

81 (10000001) Endpoint Number 1;  Direction In;

0D (00001101)   Isochronous;  

0180 Maximum Packet Size

01   

00

00

7

25

1

1

1

1

0

Thank You,

Jay

[Dean Camera]

Jay,

Very cool, I wasn't keeping up with the latest Android Accessory
protocol developments, since there didn't seem to be much of an
interest in the protocol support already in LUFA. I have a nice shiny
Android phone now, so I can look at implementing this if it is
practical when I get back to my equipment.

> I had to comment out the Audio_Host_GetSetEndpointProperty(...) part since
> AOA 2.0 only supports 44100hz (Can I do this or does it do something other
> then set the frequency?)

Yes, that's fine. Most devices support variable sampling rates
(indicated by the device descriptors) so I hard-coded the request in
the demo, but you can just turn it off if you know it won't be
required.

> Is the difference simply reading one sample, vs reading two samples in the ISR?

Yes, that will do it. I designed the demo for a USB mono microphone,
but given that the AOA protocol is backwards where your device is the
audio sink but the bus host you can just convert it to stereo by
reading multiple samples in and de-muxing.

> So is there anyway to get around the 384 byte packet size without
> switching to better processor?

Unfortunately no - you should hear mostly good sound, but with some
glitches as part of the audio stream will be truncated due to an
overrun. However, the phone might only send short packets so you might
get lucky. If it does, it will sound fine but that would be dependent
on the audio stack in Android.

> So then why does the phone show 0x0180 (384)?

Presumably that's what the USB controller in the phone supports, and
as we all know more is better right? Right?

- Dean

> >  *Size 384*

[jayjay]

Hey Dean, Thank you for your reply :)

I wanted to share with you what we are trying to do, we are using the LUFA library

for an open source Android Game Controller;

Scroll down to see the pictures :)

http://xopad2012.wordpress.com/

All the hardware is done, just trying to work the bugs out of the audio :/

As you know from my previous post on here, OTG worked great but the phone would not automatically forward the sound to the USB,

so we decided to switch to AOA 2.0. I have been working on this for some time now and have tried about 4 different devices;

Nexus Tablet, Phone, Asus Tab, Samsung S3... and some others. All running Jelly Bean 4.1 and supporting AOA 2.0 with no luck.

Some give me a packet size of 256, some 384 for the Isochronous Endpoint Type. Not sure why there is so much difference between devices since they all have the same 

Jelly Bean 4.1 kernel.

I was able to play around with the banks and hard code different buffer size in the  Audio_Host_ConfigurePipes(), and was able to get sound but it was 

miserable to say the least. Very glitchy but I could hear parts of the song :(

Some things maybe you can shed some light on;

AudioInterfaceInfo->Config.DataINPipe.Banks  = 2;

What does the 2 do? Is it for double banking vs single? So possible values are 1 and 2?

AudioInterfaceInfo->State.ControlInterfaceNumber    = AudioControlInterface->InterfaceNumber;

AudioInterfaceInfo->State.StreamingInterfaceNumber  = AudioStreamingInterface->InterfaceNumber;

AudioInterfaceInfo->State.EnabledStreamingAltIndex  = AudioStreamingInterface->AlternateSetting;

What role do these play in the library? Is there a chance the Audio_Host_ConfigurePipes() routine is setting these up incorrectly? 

Besides these, I have tried just about everything I could think of and still cannot get the audio to stream even with devices reporting a 256 byte endpoint size :(

Would love for you to give it a shot.

Thanks Again Dean!

Jay

[Dean Camera]

(Nearly cleaned out my inbox - 13 messages to go...)

> I wanted to share with you what we are trying to do, we are using the LUFA library

> for an open source Android Game Controller;

Very cool! I've got a Samsung Galaxy Nexus and a hankering for some emulated Sonic and Knuckles with a real controller, so I might just be a customer in the future. From the renderings I'll also be able to use it as a combat weapon in a pinch, so there's that too.

> I was able to play around with the banks and hard code different buffer size in the  Audio_Host_ConfigurePipes(), and was able to get sound but it was 

miserable to say the least. Very glitchy but I could hear parts of the song :(

That does sound like the USB bus is overrunning the endpoint, due to the mismatched bank size. Honestly I'm not sure there will be a good solution for this, since it's a hardware limitation of the chip. You could port over the code to a UC3A3 device which supports larger endpoints, but that would be non-trivial in terms of hardware at the very least.

> What does the 2 do? Is it for double banking vs single? So possible values are 1 and 2?

Yes, double banking of the data - that is required for Isochronous type endpoints.

> Besides these, I have tried just about everything I could think of and still cannot get the audio to stream even with devices reporting a 256 byte endpoint size :(

A bank size of 256 bytes should work - you can check that everything's working by printf() or setting a breakpoint when the device is connected, and see what values are being used in the pipe configuration routine. Note that you don't get very many cycles at all (less than 200) between sound samples at 8MHz, which means your sound code will have to be pretty tight. What are you using to render the audio, an external DAC?

Cheers!

- Dean

[jayjay]

Hey Dean!

For the first version, we are simply using two PWM channels to fake a 16 bit audio output with a Resistor DAC. The AT90USB1287 has plenty of timers so we are getting stereo audio output. We are running the uC at 16Mhz so 400 cycles between samples.

We have the prototype working, here is a demo! http://www.youtube.com/watch?v=Bzs3cfMgxW0

Its more then just a game pad, it is open source development hardware so everyone can help us make it better and tinker.

I would like to upgrade to the UC3 series to get better audio quality and handle the larger packet size of the AOA 2.0 modes.

We even got a EVK1105 evaluation board but cannot even get the demo Android Accessory code to work (also tried a few things I found for the UC3 which you wrote but could not get them to work under LUFA for now)

As of right now audio is working on the stock Galaxy S3 in OTG mode but not AOA 2.0. Hopefully future development of the Android OS will improve the audio support.

Thanks for the positive comments!

Cheers,

Jay

[Dean Camera]

Outstanding Jay - very nice product (I want to play Sonic on my Galaxy
Nexus, but hate touch controls - so I might have to look into
preordering myself).

Did you have trouble with the Atmel AOA demo, as well as the LUFA AOA
demo? I'm not sure anyone's tested it against the latest ASF 3.5.1
release (soon 3.6) but if you email support at a...@atmel.com we can
take a look for you and see if it can be fixed easily.

Cheers!
- Dean

On Jan 9, 4:19 am, jayjay <jchand...@gmail.com> wrote:
> Hey Dean!
>
> For the first version, we are simply using two PWM channels to fake a 16
> bit audio output with a Resistor DAC. The AT90USB1287 has plenty of timers
> so we are getting stereo audio output. We are running the uC at 16Mhz so
> 400 cycles between samples.
>
> We have the prototype working, here is a

> demo!http://www.youtube.com/watch?v=Bzs3cfMgxW0

> ...
>
> read more »