Hi Drew, Managed to find a backup image of the sd card from the transmitter pi on my laptop so checking through what I did, it looks like the solution was to create a file called /home/pi/.asoundrc with the following contents: pcm.!default { type hw # Kernel PCM card 0 # Card name (string) or number (integer) channels 2 # Restrict only to the given channels }

Looking at it again now it really is a bit of a hack, simply forcing the alsa system to only work in 2 channel mode, but at the time I was desperate to just get the job done. Regards, James On 22/11/2019 00:10, James Harris wrote: Hi Drew, I had the same issue when I got 4.0.3 running, I can't remember if I found a workaround to the issue or it simply went away when I used openob-gui. I will try and get my development units out on Sunday to look back. For reference, I am using the Cirrus/Wolfson sound cards on the Pi at each end, I also have an x86 box set up that I configure as one end or other of the link when I want to work on new ideas. I have some vague recollection of comparing the all of the stored redis keys when openob was started on its own to when it was started from openob-gui, but there was a lot of faffing involved and it was too long ago for it to be clear in my mind. On a completely different point, during the summer I used the system for a week over a point to point WiFi link and one of the days, during a short period of packet loss, one end of the link couldn't read keys from redis (can't remember if it was local or remote) and the link fell over. I made copious notes at the time and have the intention of adding some error handling for that condition. I believe the behaviour at the moment to simply quit openob is incorrect and that an error handling routine should pick up the condition and retry the connection either a given number of times or for a given amount of time before returning to the same state as when it is waiting to establish first connection. So probably time for me to get the whole lot back out on the bench anyway. Regards, James On 21/11/2019 23:15, drew Roberts wrote: Well, for testing purposes, I have set up 2 Pis on a local lan. Transmitting PI has usb sound card and openob uses alsa invoked like this: /usr/local/bin/openob 192.168.86.149 test-tx-node test-link tx -a alsa -d hw:1 192.168.86.149 aplay -l gives: card 1: CODEC [USB AUDIO CODEC], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 Receiving Pi uses onboard sound card and openob uses jack invoked like this: /usr/local/bin/openob 192.168.86.149 test-rx-node test-link rx -a jack -jn openob -aj -jp jack_mixer:ICh2 It is also running jack-mixer and a few other toys. After hooking things up as desired in qjackctl, I see the mono audio in jack-mixer and hear it in my headphones plugged into the Pi's soundcard. Any thoughts on how to track down the mono issue? all the best, drew -- Enjoy the *Paradise Island Cam* playing *Bahamian Or Nuttin* - https://www.paradiseislandcam.com/ _______________________________________________ openob-users mailing list -- openob-users(a)lists.talkunafraid.co.uk To unsubscribe send an email to openob-users-leave(a)lists.talkunafraid.co.uk _______________________________________________ openob-users mailing list -- openob-users(a)lists.talkunafraid.co.uk To unsubscribe send an email to openob-users-leave(a)lists.talkunafraid.co.uk _______________________________________________ openob-users mailing list -- openob-users(a)lists.talkunafraid.co.uk To unsubscribe send an email to openob-users-leave(a)lists.talkunafraid.co.uk