Distorted sound using ov-box [updated]

English ovbox
#1

Hi all! First of all, I am a very enthusiastic fresh new user of the ov-box project and I am very curious about the new musical experiment we’ll be able to do with such a neat integration of signal processing and network programming :slight_smile: So first, thanks a lot to all participants in this great project :smile: !

issue [NEW]: when I connect my ov-box via ethernet cable the other people in the room hear a very distorted sound from me while is not the case when I connect via mobile data sharing.

It is the contrary that what I had in mind… I thought the bandwidth was not sufficient in reception, but it appears that the problem comes from the transmission of my sound when using the Ethernet connection. However, surprisingly the internet connection performance is very good when doing a speed test on [geschwindigkeit.de]

I continue investigating if the my home router could be the reason…
… after few tests I have not found why my sound is sent with distortion when connecting via the ethernet cable. Maybe it has no importance, but the feedback in my headphones (with reverb from the room) is not distorted.

All the best,
Emmanuel Roux

************************ OLD POST BELOW *************************
When I (say user A) and a friend of mine (say user B) connect to a room on orlandobox [dot] com, my friend (user B) hear a very distorted sound while I (user A) can hear a perfectly clear sound.

My (user A) setup is the following :

My friend’s (user B) setup is the following :

  • ov-box (Installed with Image = firmware version : ovclient-0.5.51-c251a83)
    • 8GB raspberry Pi 4
    • other great sound card (sorry I don’t have the reference)
    • Ethernet cable connection (fiber also with very good performance up/down rates both > 100 MB/s, and jitter < 1 ms)

I’ve tried several configurations with several hardware (raspberries on both side, raps+linux client) and the common thing on all distorted signal in reception was that the receiving bandwidth was halved (even though the internet connection is of high quality) resulting in about 50% package lost (seen from my linux client outputs on the terminal).

I could reproduce the distortion by doing the following :

  • connect a first ov-client through ethernet while the other is connected through mobile data sharing. The later (network via mobile data) was systematically receiving at a rate divided by (more than) two. Swapping the USB audio devices had no impact on the results.

    • raspberry 4 (connection via mobile data sharing). sending: 0.89 MBps, receiving: 0.39 MBps CPU load: 14.1%
    • raspberry 4 (connection via ethernet). ending: 0.89 MBps, receiving: 0.89 MBps CPU load: 10.3%

I also had the opportunity to repeat the experiment thanks to the help of Petra Fiene who had the patience to investigate with me this situation (thanks again!). Again, I could hear a perfectly clear sound while on the other side the sound was received distorted… we tried the server mode (instead of the peer-to-peer mode) with no clear improvement. By the way, the receiving bandwidth was also halved by a factor of approximately two.

The positive thing is that it works very well (no distortion on any side) when using both devices on the same local network.

I would be very pleased to give any additional information to help find the distorted sound… and potentially find an explanation on the reduced bandwidth in reception compared to the sending one (strange asymmetry…).

Thanks for your attention !

All the best,
Emmanuel Roux

1 „Gefällt mir“
#2

Hi,

you are doing very good debugging, and have great ISP - congrats! Having the Cell over Wi-Fi could prove the box were fine.
I did not quite follow if recieve banwidth was half of the value of send or half the bandwidth as during Cellular connection.
Is there any switch or firewall somewhere?
Could you check, just for sanity, to set tx and rx buffers ind device settings from default 5… up to 20?

#3

Hi Daniel, thanks for your reply :slight_smile: !

Good news, I have just done my very first online rehearsal with an unbelievable sound quality and a very comfortable synchronization (total delay probably below 12 ms).

To solve the issue, I had the luck to discuss by e-mail with Giso and he found that it could potentially come from the amount small UDP packages that some internet providers limits to avoid traffic overhead at low level protocol layers. That was probably the reason for the 50% packet loss I had.

To solve it I go on the internet via another network (in practice I use a VPN) where there is not this limitation.

I also increased the UDP buffer size on my computer (I run an ov-client on my linux PC) but I am not sure if it had an effect because I didn’t evaluated the impact of this parameter individually.

Here are the various steps I perform to start a session (while my friend just had to plug the ov-box’s power supply and connect to the web interface):

# if not already done, increase UDP max mem (to print current value >>sysctl net.core.wmem_max)
$ sudo sysctl -w net.core.wmem_max=56214400
$ sudo sysctl -w net.core.rmem_max=56214400

# list available recording device
$ arecord -l

# start jack wih hardware hw:1 to use card 1  (using sampling rate 48000 Hz, and 96 samples per period (96/48000 = 2 ms)  
$ jackd -Rd alsa -d hw:1 -r 48000 -p 96 -n 2

# in another tab of terminal
$ ov-client

# access webpage using a web browser and login:
https://box.orlandoviols.com/

# if needed adjust the jitter on the web interface (but it worked well with 5 ms) : 96/48+4 = 6ms

# connect to a room and play :)

I am glad of the very nice musical moment I could share eventhough my friend was far away (yet in the same city.). However, I encountered several times a cutoff of signal (not receiving my friend’s sound for 3 or 4 seconds), here are some of the errors that were printed by the ov-client (terminal) probably linked to the temporary loss of sound :

ClientNotify fails name = tibodah_1.24ee9adc68a1 notification = 18 val1 = 1 val2 = 0
JackEngine::XRun: client = tibodah_1.24ee9adc68a1 was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = tibodah_1.24ee9adc68a1 was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot write socket fd = 23 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = 24ee9adc68a1.metronome notification = 1 val1 = 0 val2 = 0
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Cannot read socket fd = 29 err = Connection reset by peer
Could not read notification result
ClientNotify fails name = 24ee9adc68a1_sender notification = 18 val1 = 0 val2 = 0
Cannot write socket fd = 29 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = 24ee9adc68a1_sender notification = 18 val1 = 1 val2 = 0
Cannot write socket fd = 29 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = 24ee9adc68a1_sender notification = 18 val1 = 0 val2 = 0
Cannot write socket fd = 29 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = 24ee9adc68a1_sender notification = 18 val1 = 1 val2 = 0
JackEngine::XRun: client = 24ee9adc68a1_sender was not finished, state = Triggered
Cannot write socket fd = 29 err = Broken pipe
CheckRes error
Could not write notification
ClientNotify fails name = render.24ee9adc68a1 notification = 1 val1 = 0 val2 = 0

Feel free to tell me any clues on why this could happen. Thanks again and have a great weekend !

Emmanuel Roux

1 „Gefällt mir“
#4

Hi,

are you positive you did all that is possible regarding to CPU scheduling and prio? I like Ubuntu Studio or similar distros that come with PREEMT_RT and set jack + ov-client to nice= -20 and all of that. If any jack client does not get scheduled on time or takes too long, underrun happens.

You can try to have two clients in the LAN and turn all buffers to lowest possible, to see if you can reproduce it.
You can also play with 3 jack buffers or 15 to see if that is a remedy, but it does harm latency.