Some upgrade

[wiiznokes]

this should add endianess support at runtime.

it also fix a bug with TCP connection. i'm practically sure that is the same bug i encounter on Windows #21. it happens when android disconnect. The server will read a buffer with nothing in it infinitely.

Also, there is a lot a things witch don't works

• audio format, only i16 works on my machine
• stereo

And sound on Linux not work anymore :sob: But it worked at some point: 82192c0aa15e61e5a58aac595ec96bbbe67951ac.

that make me thinks: why it work on Windows ? Let's say you record with i16 format. You send values using u8 bytes. On server side, you read 2 bytes and make an i16 from it. But what prevent you of taking 2 bytes which do not form the same value?

• value1 = [byte1, byte2]
• value2 = [byte3, byte4]

and then value = [byte2, byte3]

Same for stereo, i guess i will have to look some docs at some point... But this weird that work on Windows. idk if this what you meant in this

I see haha maybe it just works because the packets carry the circular buffer offsets so they already have that ordering info.

[wiiznokes]

This is weird, i only have good result (100% success) when i use ChannelStrategy::MonoCloned with 2 channels, and I record with one channel on Android.

with ChannelStrategy::Mono and 1 channel, i get poor result, and this stats:

Stats:
elapsed: 34.27s
iteration: 11673, item moved: 1591264, item lossed: 1588416
moved by iteration: 136.32005482737944
lossed by iteration: 136.07607298894885
success: 50.0447843808182%

This means that for a single channel, the audio speed can't keep up and the buffer doesn't drain fast enough. On windows, there only one audio config supported while on Linux, there is a lot. my guess is that linux driver are too optimistic about supported config. But ChannelStrategy::Stereo, with 2 channels and record stereo should work, while it doesn't for now

[teamclouday]

And sound on Linux not work anymore

I'm just guessing right now because haven't read the code fully. Could it be packet loss? Like if it's i16 but you sent two bytes in two packets and one of them get lost so that creates an offset in the audio sequence.

This means that for a single channel, the audio speed can't keep up and the buffer doesn't drain fast enough.

Does the audio player has any specification of audio formats? Either it's because the frequency doesn't match or it's different number of channels.

[wiiznokes]

Could it be packet loss? Like if it's i16 but you sent two bytes in two packets and one of them get lost so that creates an offset in the audio sequence.

Maybe but it doesn't seem to me that there is a system to determine the start of a value yet. I imagine that for TCP, this did not pose a problem? In any case, i tested with i16, 41000 or 48000, 1 channel and UDP, and did not notice any problem. Maybe it's because for this values, there is no packet loss at all. idk.

And afterwards, to manage the endian perfectly, Android would have to share its config before starting to stream the audio.

Does the audio player has any specification of audio formats?

Yeah, you can print them with -i arg on this branch.

[wiiznokes]

it should be good to merge. There are still some parts missing but it's usable

[teamclouday]

Hey thanks for the update! I'm not by my desktop pc right now but I'll definitely check it out next week! Will try out the Rust backend :)

[teamclouday]

Sorry it takes 1 million years for me to take a look. The connection runs well, so is the Android app. I was wondering if there's something similar to python argparse in Rust. It would be helpful to be able to see all argument options in terminal. And ofc, it would be better to have GUI.

And you're right, the sound doesn't work well sometimes. My guess is it was in [byte2, byte3] situation you mentioned at beginning. I'll merge this and try to figure out the cause.

[wiiznokes]

Sorry it takes 1 million years for me to take a look

No worries

I was wondering if there's something similar to python argparse in Rust. It would be helpful to be able to see all argument options in terminal.

I think what you're looking for is clap. I already use it in the app; it's the go to crate for a terminal based app in Rust. Just use ./prog --help to see all args (the output is in the rust RDM).

And ofc, it would be better to have GUI.

Yes, Iced would be a good fit i think, i already written apps with it. But it would be nice to solve sound issues before doing an UI imo.

And you're right, the sound doesn't work well sometimes. My guess is it was in [byte2, byte3] situation you mentioned at beginning. I'll merge this and try to figure out the cause.

Looking forward to see this :smile: