22 Nov
2019
22 Nov
'19
12:29 a.m.
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 toopenob-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