...
- From the analysis point of view we are done
- Let's see if we can talk about implementation
- if OpenAvenue is providing the AVB a complete Network Audio Synchronization out of the box, then there is nothing to do, but if not, then this is a potential improvement
- It can also be useful even if it's just showing the integration of the solution to Android.
- AVB can run on software only so the integration can be an implementation target.
- What about working on the integration to show the code before 23rd of December?
- it's gonna a bit hard to almost undoable
- A2B has a pre-liminary linux Linux driver that but we if we can configure this and prepare it for integration that would be a topic for the Fosdem
- is A2B compatible with I2S?
- yes I2S and I2C
- But sort of an emulated I2S and I2C
- is the A2B its own hardware trancievertransceiver? yes
- in summary: A2B is a bus transfer of I2S and I2C
- is A2B compatible with I2S?
- Another thing that we can try:
- I2C and I2S lines out of the Android platform and we can have A2B on an external board
- we connect the I2C and I2S to the A2B toolkit to control it
- Android (having: I2C + I2S_1 I2S_2) <==> A2B devkit <==> A2B remote1/remote2
- How does A2B operates if i want to send a stream to both remote 1 and remote 2? I2C has for example Left and right flag
- you could put it in bus slot and configure the slot to be picked up by remote 1 and remote 2
- bus slot is an A2B concept (converted data from I2S to A2B)
- the tranciever transceiver of A2B would then multiplex the data to different bus slot
- Yes this idea falls into the scope of Audio_HAL
- Could we take an ALSA device into the linux Linux driver?
- The linux Linux driver in the A2B is already supporting ALSA
- Details about the Bus and audio attribute (Unknown User (wassim.filali) + Suhasini Raghuram)
- We are capable in Android to map a bus according to the attribute
- So each of the remote can become a bus on its own
- it would be useful to send every Audio usage can go to different remote
- Isn't AVB a p2p?
- we can use AVB on a network and work with mac addresses
- AVB being derived from the network, it can do what a network does
- You have two technology to send audio through the network:
- One node to another (A2B)
- Network (AVB)
- so our discussion of the AVB in the Breakdown rework AVB page can have two solutions (AVB and A2B)
- These are the most attractive technologies to work on it
- We can propose this idea as a stepping stone for building a network Audio in Android (A2B + I2S/I2C)
- We can start with small code base and compliment it with plans for the future
- The only problem is that we are not sure how open the Android/A2B topic is
- The software part would be open but the development board (Android + A2B) is hard to get
- Actually this is an advantage point not an issue. We know that the hardware is needed but if we can show that our solution works with Software only, then it's very good
- Devkit software: free but no opensource → there are plans to make it open source (it's in the roadmap)
- Summary: There is an opportunity for Suhasini Raghuram to create a plan, presentation, and show implementation in the Fosdem (if we are able to meet the deadline 23rd December)
- repo + license should be ready
- This is nice because it might trigger the curiosity of some developers
- Need to check from Suhasini Raghuram if the open source part can be done
- Can we check that the presentation could be ready before 23rd of December but the code should be ready before the presentation
...