Android support

[corrados]

This issue has been migrated from Sourceforge. Created: 2015-12-13
Creator: Volker Fischer

Add support for the Android operating system. The software can already be compiled for Android but the audio interface does not work right now. So the first step is to finish the audio interface implementation. As a second step, all GUI functionality must be checked that it is possible to use it with a touch screen only.

[corrados]

Some progress reported here: https://sourceforge.net/p/llcon/discussion/533517/thread/cfd165e0/#452b/6e3b

[corrados]

See here: https://www.facebook.com/groups/507047599870191/permalink/521878088387142/

[j-santander]

Is there any instructions on how to build this? or any specific branch/forked repository I could refer to? From the previous links there seems to be some implementation working to some extent. I might be able to give a hand, at least testing
Thanks

[corrados]

The code on master is from Simon. But it does not work correctly. Recently, I have started a branch where I do some testing. But also, nothing working yet.

[j-santander]

Ok, thanks. I got it to compile and started testing.

There's an mistake on android/sound.cpp: on CSound::onAudioRead() when converting from incoming float buffer to int16_t:

                pSound->vecsTmpAudioSndCrdStereo[frmNum * oboeStream->getChannelCount() + channelNum] =
                    (short) floatData[frmNum * oboeStream->getChannelCount() + channelNum] * _MAXSHORT;

should be

                pSound->vecsTmpAudioSndCrdStereo[frmNum * oboeStream->getChannelCount() + channelNum] =
                    (int16_t)(floatData[frmNum * oboeStream->getChannelCount() + channelNum] * _MAXSHORT);

otherwise the precedence of the casting operator will make the input always 0.

Changing that if I write to a file the content pSound->vecsTmpAudioSndCrdStereo vector I got a correct signal.

To continue progressing I might need to understand better how the whole things work (I'm not at all familiar with neither your code or even the oboe library). A few doubts:

• Is it assumed that the sound card is always stereo? It seems so, but the oboe library seems to be configured in Mono. Changing that I seemed to started receiving a more-or-less-ok signal on another client. What other assumptions should be made for the signal coming from CSound -> CClient (sampling rate, frame size....)?
• You got oboe setup for float samples. Is there any reason to not use int16_t samples? (we're doing the conversion by hand).
• I'm not sure how it works on the playing side. What I believe I see is that at CClient::ProcessAudioDataIntern after the recording data is processed, the same vector used for the recording data is filled with the playing data received from the network. However, my expectation is that I would be receiving an independent call to CSound::onAudioRead() for the playing channel, which might even indicate that the number of frames available for writing is not the same as the number of frames that we've written (however there seem to be an oboe builder call: setFramesPerCallback() that might help in synchronizing).
• What are the expectations for the CClient -> CSound data?
• How the expected buffer sizes work? (both for playing and recording)

In this last case, I'd go probably for a temporary circular buffer where the onAudioRead() processing of input data will write the recording data left in the buffer and the call of onAudioRead() for the output data will read. It probably would need to be mutex protected (unless we can be sure that the oboe callbacks are always run on the same thread)

[corrados]

There's an mistake on android/sound.cpp: on CSound::onAudioRead() when converting from incoming float buffer to int16_t

I'll merge from a branch soon, where the int 16 type is replaced by float.

Is it assumed that the sound card is always stereo?

Yes, the input/output audio vector for the audio interfaces is assumed to be always stereo. If you have only a mono stream available, just write the same audio data in both stereo channels.

On my branch https://github.com/corrados/jamulus/tree/android_testing I tried to use the full duplex oboe example class. But it is not yet finished. There is function onBothStreamsReady which should have the same size for input and output (which is what Jamulus expects).

[j-santander]

I've got some working code at j-santander@a3558aa
(Unfortunately I was mistakenly working from the master code, not from the android_testing branch.. and only when I was ready to submit I realized of my mistake).

In my tests I can hear other clients and they can hear me. Not sure of the overall quality of sound.

Key modification was to setup the callback only on the input stream and do explicit write to the output stream after processing the incoming data.

I'll try to have a look at the code in the android_testing branch and incorporate it.

Let me know what you think or how should I proceed.

Cheers

[corrados]

My code on the android_testing branch is not working. I was just experimenting a bit. You do not need to use any of that code. If you have something working, then you could create a pull request. I can then test it on my Android phone. But be aware that some minutes ago I applied a big change to the code on master.

[j-santander]

Created PR #661.

Thanks