Networked Audio in Android Automotive, Extracting RAW PCM streams
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Raghuram, Suhasini
Krawczyk, Piotr
The modern vehicle audio system is built with a number of networked components that are needed for many complex and integrated functionalities such as active noise cancellation, warning sounds, diagnostics, etc. And thus, complex and flexible audio setups are a fundamental design need for modern vehicles. GENIVI AASIG analyzes various scenarios of integrating Android in this complex setup and analyzes the maturity and gaps of Android Automotive solution in this context. This talk aims to highlight some of the findings of the group and discuss further investigation topics in this area The talk will give a short overview of the audio system design choices with Android. As part of the analysis towards integrating Android in the complex setup that exists today, the first step group took was to extract raw PCM stream out of Android context. The talk will discuss the implementation of this and the various design tradeoffs and decisions that was taken. The next step would be to connect Android to audio network. Currently A2B and AVB are being investigated. Further investigations includes topics like: ECNR handling, calibration mechanisms, how to utilize DSPs in various system configuration (virtualization, containerization, multi HW).
 Hello, my name is Suhasini. I work as a software developer at Analog Devices. My colleague, Peter and I are here to talk about network audio in Android Automotive and some of our work done as part of the Genevieve Android Automotive Special Interest Group. Using Android in the Automotive domain is not as easy as it is in the smartphones. And that is because of the various complex applications and cars. Just to give you a brief about the various applications, we have some applications in the power train with battery management and fuel level indicators. And then we have the infotainment segment which has telephony and voice assistance similar to the phones. But other applications like rare seat entertainment units and complex audio processing applications like noise cancellation which are much more complicated than the phones. We also have ADAS or the advanced driver assistance systems like cruise control or parking assist, etc. And then with the autonomous driving evolving fast, we also have a lot of perception. And control applications coming up. And then there's the connected car applications with vehicle to vehicle and vehicle to everything connectivity. These are just some of the applications. There are a lot more applications in the cars. And all of these applications are realized via various networks in car like A to B, CAN, LEN, etc. So the question really was can Android Automotive cater to all these needs of these applications? And we wanted to investigate further but more in the audio and infotainment segment. So we started with the audio system design architecture. We wanted to see what are the various rules that Android could play in this audio system, the audio subsystem in the car. A common car audio system architecture is shown in this diagram here. You have the head unit and an amplifier in the trunk, some speakers and mics and also the rear seat entertainment unit. We have more mics and speakers for more advanced system applications. With such a system there comes various system design approaches. One of the options is that Android only provides the sources and syncs and the rest of the configuration and the controlling and processing of audio happens externally. Another option is for Android to control the system completely to do the configuring and the controlling as well as provide some sources and also do the audio routing all by itself. Now these two are actually extreme options and we can't say that just one of them will be used because in most systems there will be a need for a combination of both of these coexisting. Like for example in the system shown just some time ago maybe the rear seat entertainment unit might use the first approach giving out only the source and syncs because in a sense it's a lean node and without much complexity. But with the head unit operating system maybe it takes the second approach controlling the entire system doing the processing and routing. And sometimes maybe it might also be that Android is merely routing the audio streams but then the configuring of the entire system and controlling happens from somewhere else. So we really need to have Android be flexible to all of these approaches. One problem statement which was common to all of these approaches was that extracting raw PCM streams out of the Android context. And we started to investigate this as the first step. Pauling Piotr will give an overview of our POC. Hi, my name is Piotr Kraptrik, I'm a Tieto-Evry employee and a member of GeneVy team. This is the first design that we've had in mind intention was to find out what are the challenges when implementing audio hold without support of SOC vendors. We assumed we would like to have hardware independent solution that will expose audio data to external clients for further processing. Either it would be just playback, applying additional audio effects or mixing with another audio sources. We wanted also to check if there is a need for additional service or feature. That's the reason why you can see here a separate GeneVy audio framework and GeneVy audio how. We were planning to adhere any features that we believe Android is lacking. At the time when we were doing this design we've encountered some missing features or problems with for example defining non-linear volume curve or means to control audio effects globally by the system, not by the applications that can be used for calibration of the platform. But currently Android already is somehow improved or solved the problems. So this is still empty placeholder and there is no real functionality behind it. But still we are investigating other possible gaps and features because Android was designed to work with phones not with automotive environment and mobile configuration is rather straightforward compared to one that we can found on mobile cars like plenty of speakers, safety sounds, external amplifiers or audio zones. At the same time Android is still evolving and we can see much of the new features coming with Android new versions. So still we've got this placeholder but it's for this moment and for this POC empty. For demonstration purposes we chose X86 platform. It gave us possibility to utilize pure ASP code with already working emulator. The setup shows also that hardware independent solution should work also in virtual environment that is common solution nowadays as Android can be treated as kind of a virtual device and in this configuration is working with Linux virtual machine. It somehow actually looks like some Jiggle automotive setup with hypervisor and host and guest. Android is also putting some effort in virtualization adding virtual support and creating projects like trout and cuttlefish that can be used as testing facility. This POC was actually run with Android Q emulator running on Windows host and Ubuntu 18 deployed on virtual box virtual machine. Using with emulator and virtual machine is based on DCP that is realized by the virtual box routing mechanisms. So the following components was created for this POC. We've got additional device configuration. It's based on automotive variant for X86 target. We have created audio hall that is derived from emulator and audio relay component that is responsible for forwarding audio data from audio hall to external clients. Zones and audio context features of Android can be still utilized as content for those who are transferred via separate sockets in this case external client can manipulate the volume or mix it with other sources depending on priorities that can be configured there. So configuration of context and zones are also delivered with this POC for the demonstration purposes we've defined two zones. In first zone context are separated in second zone they are mixed together and delivered by a single channel. This configuration can be easily changed and adopted to current needs. This diagram shows audio data flow in current concept. Note that the audio hall serves audio data via named sockets to audio relay. Reason behind is that Android selling policies forbids how to communicate via network socket. Other solution more tailored to chosen configuration can be of course applied like shared memory or other platform IPCs so in this case audio relay component can be removed from the flow. So in the end we've got simple prototype solution that allows to get audio data from Android and pass it to external receiver like host, audio subsystem or external amplifier. You can get the code from the mentioned link. Feel free to use it, comment it and suggest any changes. Thank you. Thank you. When we talk about the role of Android it's not just confined to the head unit especially if we're talking about cases where it's used as the master controller. It will have to interact with several other hardware some on the same SOC and some others elsewhere in the car connected via network and this is where it slightly differs from phones because in phones the Android operating system need not worry about a device that is far off somewhere down in the network but in car it is a very real use case, a very possible scenario where you have the trunk amplifier or a race seat entertainment which is connected to your head unit via a network. So we need to Android to be able to control or operate these remote nodes as well and not only would we be controlling the devices like trunk amplifier or RSC we also have the task of transporting the audio itself over the network and to do that we have protocols like audio video bridging or A to B which help with this each having its own pros and cons of course. In the following slides we will just briefly talk about the two protocols that we are investigating in this group for integration with Android, AVV and A to B and also provide some resources for their open source code. Audio video bridging or TSM as it is now called is a series of standards which was brought in to help realize the time sensitive applications over Ethernet. So Ethernet in essence has a few hurdles when it comes to catering to audio applications that one of them is that there is no concept of time in Ethernet its packets and it is also asynchronous communication asynchronous transmission and each device has its own clock and when we talk about audio transmission we of course needed to be synchronous. So to overcome this we came up with the GPTP protocol or the 802.1 AS protocol and to cater to delays that are non-deterministic they introduced the 802.1 Q AV standard and stream reservation protocol was introduced to cater to bandwidth reservation needs and 1722 or the audio video transport protocol for interoperability. There are many more standards in this. The AVTP protocol has a line-up implementation and it's linked here. The next link the TSM.ReadTheDux link has a nice document on getting started with AVV. The other network we investigated is the automotive audio bus. This is a low latency digital bus for high-fidelity audio. It can transport multi-channel audio with a deterministic latency of less than 50 microseconds. AVB is a synchronous bus so it also has a clock on the same bus. In addition to audio you can also send some control information with I2C over distance and GPIO over distance and even the other nodes on the network are all powered by the bus itself so you don't need any specific any separate power supplies to these other nodes. Some implementation for A2B already exists and there is a link to the kernel driver here. This is not yet in the mainstream line-up there is still some work left to get it there but it should get you started. Both A2B and AVV have line-up implementations that needs to be extended to Android. The next step would be to integrate a network and connect the raw streams that we extracted from the POC to the audio network. And not just this there are tons of other avenues that need to be investigated. Some of them are listed here. It could be the Bluetooth headset handling which is quite different from the phone in the fact that when you're talking about the phone Bluetooth module that acts as a master but then in the car the Bluetooth module has to act like the receiver. And some other audio processing like ECNN handling for voice or other audio processing algorithms that needs to be run on external DSP. There's also some calibration mechanisms that we can further look at how to support them in Android. And there is also utilizing the DSPs in various system configurations. We could have a virtual machines or containers or actual multiple hardware. And it's also when we have virtual machines or containers how do we pass audio streams between different virtual machines or containers that that also would be a point of investigation. And then there's this aspect of latency in Android. So how much of latency would Android add and is there a scope for reducing that when we want low latency what is the path that people want to take. These are some investigation points that are a lot more of them that needs to be investigated. This was the team that was working on this presentation. So our contact details are here. You have the ASAG mailing list link. We also have contact details for myself, Piotr Rovaseem here. Please do join us at the ASAG Audio Hardworking Group to contribute. You could email us at the mailing list to join. And also if you want to find out more about this group please visit the Viki page, the link here. Thank you so much for listening to us. Okay so thank you very much, Seohoshini and Piotr. So questions and answers. So we have a question on the hardware. Hang on a second. Okay so could you give more details of the hardware side of the automotive bus, e.g. number of wires, max length, bandwidth, etc. Okay, take it away. So the number of wires A to B connects with a twisted pair cable, unshielded twisted pair so it's just a pair of wires between two nodes. The max length between two nodes can be up to 10 meters and the total length of the entire network from the master to your last sleeve would be 40 meters. And what was the other thing? Max bandwidth. Bandwidth is about 50 Mbps in A to B today. Okay cool. So in general in working with Android in automotive, how have you noticed that over the several versions of Android, how have you noticed things changing? Do you think that the Android developers are getting a better idea of how automotive audio works? Maybe this is more to me. Yeah definitely. It seems that from release to release there is more attention paid to the audio side beginning starting with this audio zones features that came sometime ago and now this should be fully working connected to the multi-display features so that each display should have its own audio zone that can be switched also by the system. And yeah it was actually a bit redesigned compared to the mobile world and I expect some new also changes coming through with new releases. So definitely audio is something that Android developers paying attention to. I think that currently we will have some work put to the virtualization side so the virtual sound utilization. But let's see this coming. So if I understand rightly your approval concept was based on Android 10 is that right? Yeah actually we started I think even online, I started thinking of it but in the end it was based on what we can find in Android 10. Okay cool. And have you looked at updating to Android 11 or is that not an issue? No we haven't been considering it right now. I think that we have to think about this virtualization issue and perhaps base communication on some future setup. This could be something quite interesting to explore. Cool. Okay and one final thing I'd like to throw out there. So you are both working in the context of the Genevieve special interest group on Android automotive. Could you tell people a little bit about that group and how people can join in to it and yeah what kind of things do you do in general? Well I could answer that. So Genevieve automotive, Android automotive special interest group was formed to look at how Android automotive, what design changes can be there or what improvements can be there in Android automotive for the various applications that are coming up today. We have two subgroups here, one is the vehicle HAL and the other one is the audio HAL subgroup. I can speak more on the audio HAL subgroup. We are investigating several topics around audio in Android automotive. So right now we are investigating the network audio devices but then there are other topics that we would be investigating like some of them were already mentioned in the talk but we do have some section for Bluetooth. There's this topic on latency and how that can be handled in the car and several other topics that are there. People can join this group by writing a mail to the mailing list. I can just put the link in the chat here and yeah there's also a wiki page that people can look at to understand the various other projects that are there and how they can join as well. Maybe I can say several words about the second stream this vehicle HAL. It's up to somehow combine the world of Android where the component responsible for providing data from automotive is predefined by Google to something about 80 values but in the automotive world there are some models consisting of thousands actually and tens of thousands of values that can be somehow of use to applications and in this vehicle HAL group people are working on trying to combine those two worlds and get the common idea how to serve those two applications in some useful way. Okay good well I wish you every success with your work on Android automotive and with Junivy. So unless you have anything further to say I will close this chat down. So I want to thank you both very much once more for a very interesting talk and yeah we hope to see you again at FOSDEM next year. Thank you. Thank you. Bye.
 Hello, my name is Suhasini.  I work as a software developer at Analog Devices.  My colleague, Peter and I are here to talk about network audio in Android Automotive  and some of our work done as part of the Genevieve Android Automotive Special Interest Group.  Using Android in the Automotive domain is not as easy as it is in the smartphones.  And that is because of the various complex applications and cars.  Just to give you a brief about the various applications, we have some applications in  the power train with battery management and fuel level indicators.  And then we have the infotainment segment which has telephony and voice assistance similar  to the phones.  But other applications like rare seat entertainment units and complex audio processing applications  like noise cancellation which are much more complicated than the phones.  We also have ADAS or the advanced driver assistance systems like cruise control or parking assist,  etc.  And then with the autonomous driving evolving fast, we also have a lot of perception.  And control applications coming up.  And then there's the connected car applications with vehicle to vehicle and vehicle to everything  connectivity.  These are just some of the applications.  There are a lot more applications in the cars.  And all of these applications are realized via various networks in car like A to B, CAN,  LEN, etc.  So the question really was can Android Automotive cater to all these needs of these applications?  And we wanted to investigate further but more in the audio and infotainment segment.  So we started with the audio system design architecture.  We wanted to see what are the various rules that Android could play in this audio system,  the audio subsystem in the car.  A common car audio system architecture is shown in this diagram here.  You have the head unit and an amplifier in the trunk, some speakers and mics and also  the rear seat entertainment unit.  We have more mics and speakers for more advanced system applications.  With such a system there comes various system design approaches.  One of the options is that Android only provides the sources and syncs and the rest of the configuration  and the controlling and processing of audio happens externally.  Another option is for Android to control the system completely to do the configuring and  the controlling as well as provide some sources and also do the audio routing all by itself.  Now these two are actually extreme options and we can't say that just one of them will  be used because in most systems there will be a need for a combination of both of these  coexisting.  Like for example in the system shown just some time ago maybe the rear seat entertainment  unit might use the first approach giving out only the source and syncs because in a sense  it's a lean node and without much complexity.  But with the head unit operating system maybe it takes the second approach controlling the  entire system doing the processing and routing.  And sometimes maybe it might also be that Android is merely routing the audio streams  but then the configuring of the entire system and controlling happens from somewhere else.  So we really need to have Android be flexible to all of these approaches.  One problem statement which was common to all of these approaches was that extracting  raw PCM streams out of the Android context.  And we started to investigate this as the first step.  Pauling Piotr will give an overview of our POC.  Hi, my name is Piotr Kraptrik, I'm a Tieto-Evry employee and a member of GeneVy team.  This is the first design that we've had in mind intention was to find out what are the  challenges when implementing audio hold without support of SOC vendors.  We assumed we would like to have hardware independent solution that will expose audio  data to external clients for further processing.  Either it would be just playback, applying additional audio effects or mixing with another  audio sources.  We wanted also to check if there is a need for additional service or feature.  That's the reason why you can see here a separate GeneVy audio framework and GeneVy audio how.  We were planning to adhere any features that we believe Android is lacking.  At the time when we were doing this design we've encountered some missing features or  problems with for example defining non-linear volume curve or means to control audio effects  globally by the system, not by the applications that can be used for calibration of the platform.  But currently Android already is somehow improved or solved the problems.  So this is still empty placeholder and there is no real functionality behind it.  But still we are investigating other possible gaps and features because Android was designed  to work with phones not with automotive environment and mobile configuration is rather straightforward  compared to one that we can found on mobile cars like plenty of speakers, safety sounds,  external amplifiers or audio zones.  At the same time Android is still evolving and we can see much of the new features coming  with Android new versions.  So still we've got this placeholder but it's for this moment and for this POC empty.  For demonstration purposes we chose X86 platform.  It gave us possibility to utilize pure ASP code with already working emulator.  The setup shows also that hardware independent solution should work also in virtual environment  that is common solution nowadays as Android can be treated as kind of a virtual device  and in this configuration is working with Linux virtual machine.  It somehow actually looks like some Jiggle automotive setup with hypervisor and host  and guest.  Android is also putting some effort in virtualization adding virtual support and creating projects  like trout and cuttlefish that can be used as testing facility.  This POC was actually run with Android Q emulator running on Windows host and Ubuntu 18 deployed  on virtual box virtual machine.  Using with emulator and virtual machine is based on DCP that is realized by the virtual  box routing mechanisms.  So the following components was created for this POC.  We've got additional device configuration.  It's based on automotive variant for X86 target.  We have created audio hall that is derived from emulator and audio relay component that  is responsible for forwarding audio data from audio hall to external clients.  Zones and audio context features of Android can be still utilized as content for those  who are transferred via separate sockets in this case external client can manipulate the  volume or mix it with other sources depending on priorities that can be configured there.  So configuration of context and zones are also delivered with this POC for the demonstration  purposes we've defined two zones.  In first zone context are separated in second zone they are mixed together and delivered  by a single channel.  This configuration can be easily changed and adopted to current needs.  This diagram shows audio data flow in current concept.  Note that the audio hall serves audio data via named sockets to audio relay.  Reason behind is that Android selling policies forbids how to communicate via network socket.  Other solution more tailored to chosen configuration can be of course applied like shared memory  or other platform IPCs so in this case audio relay component can be removed from the flow.  So in the end we've got simple prototype solution that allows to get audio data from  Android and pass it to external receiver like host, audio subsystem or external amplifier.  You can get the code from the mentioned link.  Feel free to use it, comment it and suggest any changes.  Thank you.  Thank you.  When we talk about the role of Android it's not just confined to the head unit especially  if we're talking about cases where it's used as the master controller.  It will have to interact with several other hardware some on the same SOC and some others  elsewhere in the car connected via network and this is where it slightly differs from  phones because in phones the Android operating system need not worry about a device that  is far off somewhere down in the network but in car it is a very real use case, a very  possible scenario where you have the trunk amplifier or a race seat entertainment which  is connected to your head unit via a network.  So we need to Android to be able to control or operate these remote nodes as well and  not only would we be controlling the devices like trunk amplifier or RSC we also have the  task of transporting the audio itself over the network and to do that we have protocols  like audio video bridging or A to B which help with this each having its own pros and  cons of course.  In the following slides we will just briefly talk about the two protocols that we are  investigating in this group for integration with Android, AVV and A to B and also provide  some resources for their open source code.  Audio video bridging or TSM as it is now called is a series of standards which was brought  in to help realize the time sensitive applications over Ethernet.  So Ethernet in essence has a few hurdles when it comes to catering to audio applications  that one of them is that there is no concept of time in Ethernet its packets and it is  also asynchronous communication asynchronous transmission and each device has its own clock  and when we talk about audio transmission we of course needed to be synchronous.  So to overcome this we came up with the GPTP protocol or the 802.1 AS protocol and to cater  to delays that are non-deterministic they introduced the 802.1 Q AV standard and stream  reservation protocol was introduced to cater to bandwidth reservation needs and 1722 or  the audio video transport protocol for interoperability.  There are many more standards in this.  The AVTP protocol has a line-up implementation and it's linked here.  The next link the TSM.ReadTheDux link has a nice document on getting started with AVV.  The other network we investigated is the automotive audio bus.  This is a low latency digital bus for high-fidelity audio.  It can transport multi-channel audio with a deterministic latency of less than 50 microseconds.  AVB is a synchronous bus so it also has a clock on the same bus.  In addition to audio you can also send some control information with I2C over distance  and GPIO over distance and even the other nodes on the network are all powered by the  bus itself so you don't need any specific any separate power supplies to these other  nodes.  Some implementation for A2B already exists and there is a link to the kernel driver  here.  This is not yet in the mainstream line-up there is still some work left to get it there  but it should get you started.  Both A2B and AVV have line-up implementations that needs to be extended to Android.  The next step would be to integrate a network and connect the raw streams that we extracted  from the POC to the audio network.  And not just this there are tons of other avenues that need to be investigated.  Some of them are listed here.  It could be the Bluetooth headset handling which is quite different from the phone in  the fact that when you're talking about the phone Bluetooth module that acts as a master  but then in the car the Bluetooth module has to act like the receiver.  And some other audio processing like ECNN handling for voice or other audio processing  algorithms that needs to be run on external DSP.  There's also some calibration mechanisms that we can further look at how to support  them in Android.  And there is also utilizing the DSPs in various system configurations.  We could have a virtual machines or containers or actual multiple hardware.  And it's also when we have virtual machines or containers how do we pass audio streams  between different virtual machines or containers that that also would be a point of investigation.  And then there's this aspect of latency in Android.  So how much of latency would Android add and is there a scope for reducing that when  we want low latency what is the path that people want to take.  These are some investigation points that are a lot more of them that needs to be investigated.  This was the team that was working on this presentation.  So our contact details are here.  You have the ASAG mailing list link.  We also have contact details for myself, Piotr Rovaseem here.  Please do join us at the ASAG Audio Hardworking Group to contribute.  You could email us at the mailing list to join.  And also if you want to find out more about this group please visit the Viki page, the  link here.  Thank you so much for listening to us.  Okay so thank you very much, Seohoshini and Piotr.  So questions and answers.  So we have a question on the hardware.  Hang on a second.  Okay so could you give more details of the hardware side of the automotive bus, e.g.  number of wires, max length, bandwidth, etc.  Okay, take it away.  So the number of wires A to B connects with a twisted pair cable, unshielded twisted  pair so it's just a pair of wires between two nodes.  The max length between two nodes can be up to 10 meters and the total length of the entire  network from the master to your last sleeve would be 40 meters.  And what was the other thing?  Max bandwidth.  Bandwidth is about 50 Mbps in A to B today.  Okay cool.  So in general in working with Android in automotive, how have you noticed that over  the several versions of Android, how have you noticed things changing?  Do you think that the Android developers are getting a better idea of how automotive  audio works?  Maybe this is more to me.  Yeah definitely.  It seems that from release to release there is more attention paid to the audio side beginning  starting with this audio zones features that came sometime ago and now this should be fully  working connected to the multi-display features so that each display should have its own audio  zone that can be switched also by the system.  And yeah it was actually a bit redesigned compared to the mobile world and I expect  some new also changes coming through with new releases.  So definitely audio is something that Android developers paying attention to.  I think that currently we will have some work put to the virtualization side so the virtual  sound utilization.  But let's see this coming.  So if I understand rightly your approval concept was based on Android 10 is that right?  Yeah actually we started I think even online, I started thinking of it but in the end it  was based on what we can find in Android 10.  Okay cool.  And have you looked at updating to Android 11 or is that not an issue?  No we haven't been considering it right now.  I think that we have to think about this virtualization issue and perhaps base communication on some  future setup.  This could be something quite interesting to explore.  Cool.  Okay and one final thing I'd like to throw out there.  So you are both working in the context of the Genevieve special interest group on Android  automotive.  Could you tell people a little bit about that group and how people can join in to it and  yeah what kind of things do you do in general?  Well I could answer that.  So Genevieve automotive, Android automotive special interest group was formed to look at  how Android automotive, what design changes can be there or what improvements can be there  in Android automotive for the various applications that are coming up today.  We have two subgroups here, one is the vehicle HAL and the other one is the audio HAL subgroup.  I can speak more on the audio HAL subgroup.  We are investigating several topics around audio in Android automotive.  So right now we are investigating the network audio devices but then there are other topics  that we would be investigating like some of them were already mentioned in the talk but  we do have some section for Bluetooth.  There's this topic on latency and how that can be handled in the car and several other  topics that are there.  People can join this group by writing a mail to the mailing list.  I can just put the link in the chat here and yeah there's also a wiki page that people  can look at to understand the various other projects that are there and how they can join  as well.  Maybe I can say several words about the second stream this vehicle HAL.  It's up to somehow combine the world of Android where the component responsible for providing  data from automotive is predefined by Google to something about 80 values but in the automotive  world there are some models consisting of thousands actually and tens of thousands of  values that can be somehow of use to applications and in this vehicle HAL group people are working  on trying to combine those two worlds and get the common idea how to serve those two  applications in some useful way.  Okay good well I wish you every success with your work on Android automotive and with Junivy.  So unless you have anything further to say I will close this chat down.  So I want to thank you both very much once more for a very interesting talk and yeah  we hope to see you again at FOSDEM next year.  Thank you.  Thank you.  Bye.
networked_audio_in_android_0_167.png networked_audio_in_android_168_647.png networked_audio_in_android_648_1223.png networked_audio_in_android_1224_2231.png networked_audio_in_android_2232_3275.png networked_audio_in_android_3276_4319.png networked_audio_in_android_4320_6995.png networked_audio_in_android_6996_10739.png networked_audio_in_android_10740_16787.png networked_audio_in_android_16788_19199.png networked_audio_in_android_19200_21527.png networked_audio_in_android_21528_23303.png networked_audio_in_android_23304_23819.png networked_audio_in_android_23820_23891.png networked_audio_in_android_23892_26159.png networked_audio_in_android_26160_27119.png networked_audio_in_android_27120_27167.png networked_audio_in_android_27168_27227.png networked_audio_in_android_27228_27503.png networked_audio_in_android_27504_27947.png networked_audio_in_android_27948_28043.png networked_audio_in_android_28044_28571.png networked_audio_in_android_28572_28727.png networked_audio_in_android_28728_28799.png networked_audio_in_android_28800_29711.png networked_audio_in_android_29712_30119.png networked_audio_in_android_30120_30359.png networked_audio_in_android_30360_30407.png networked_audio_in_android_30408_32087.png networked_audio_in_android_32088_32195.png networked_audio_in_android_32196_32483.png networked_audio_in_android_32484_32663.png networked_audio_in_android_32664_33155.png networked_audio_in_android_33156_33839.png networked_audio_in_android_33840_36287.png networked_audio_in_android_36288_37619.png networked_audio_in_android_37620_38327.png networked_audio_in_android_38328_38387.png networked_audio_in_android_38388_38507.png