search

sm0svx / svxlink

Advanced repeater system software with EchoLink support for Linux including a GUI, Qtel - the Qt EchoLink client
http://svxlink.org/
Other
433 stars 170 forks source link

Keep audio devices open all the time, and from start of program #96

Closed pe1chl closed 5 years ago

pe1chl commented 10 years ago

We are now working on the streaming audio via svxlink, Alsa loopback device and darkice. It appears to be working now, will do some more testing and tweaking and hopefully some doc.

What caused some problems is the fact that svxlink closes the audio device every time it turns off the transmitter. It causes issues with the startup sequence of svxlink, darkice and the parameters of the Loopback interface.

I have been able to overcome them but it requires a mod to darkice. It would work without problem when svxlink would have the option to keep the output device (in this case a second local transmitter with output to alsa:hw:Loopback,0,0) open from the startup of the program until closedown. (instead of only from beginning to end of transmission)

Apparently it was done to work with cards that can only do half-duplex. If possible, detect this situation during startup (e.g. open the soundcard for receive and transmit and only close the card for every tx swich when this fails). When it is not possible, please add a config flag that forces svxlink to keep the card open. Consider that a soundcard may be used only for transmit, and that it should be possible to keep it open in that case as well.

sm0svx commented 10 years ago

Actually there already is a function Async::AudioDevice::isFullDuplexCapable() that report if a sound card is full duplex capable or not. The only thing left is to implement the logic in LocalTx. It's probably pretty simple to do.

Dloranger commented 5 years ago

I think this might fix one of the issues I have been fighting with high channel count sound cards, is there any plans to fix it?

also, I don't mind experimenting a bit.

Is this roughly the correct place to edit in the new code, line 887 of LocalTx.cpp? image

pe1chl commented 5 years ago

Unfortunately there appears to be little development. When you want to try a solution external to svxlink, look at the possibilities of alsa configuration (via the file /etc/asound.conf) where you can setup complicated structures of plugins to route the audio from virtual soundcards to the physical card. E.g. with "dmix" you can create a mixer that combines the outputs of several sessions into a single card, translating channel numbers along the way. Maybe you can solve your problem with that. We use dsnoop and dmix to run different instances of svxlink and remotetrx alongside using shared soundcards.

Dloranger commented 5 years ago

I am using the alsa stuff already, but alas, it is not being predictable in terms of getting stuff to play nicely. I will keep plugging (pun intended) along and see if I can make some headway, was just hoping someone might know roughly what is going on as I have been fighting with this for about a year on and off with multiple sound card types.

sm0svx commented 5 years ago

Latest master may solve this issue. Keep audio devices open by setting AUDIO_DEV_KEEP_OPEN=1 in a local RX or TX section. However, audio devices does not open immediately when the application starts but rather on first use.

Reopen issue if unresolved.

dl1hrc commented 5 years ago

please could you explain why we do not open the audio device and remain it open until SvxLink will be closed? What is the advantage of doing it this way?

pe1chl commented 5 years ago

now the issue has been re-opened anyway: also note that not opening the device immediately but only on first use does not solve our issue. it may solve other user's problems (those that have unreliable drivers that fail when opened and closed repeatedly) but it still does not work nicely with loopback devices, which need to get their configuration at the start.

sm0svx commented 5 years ago

This was the easiest solution right now to solve the issue with the Fe-Pi audio device. The audio device will be kept open until SvxLink exits but it will not open until first use.

sm0svx commented 5 years ago

It will probably not take much to resolve this issue as well. I'll have a quick look.

sm0svx commented 5 years ago

Happy now? ;-)

pe1chl commented 5 years ago

You have again updated it? It is nice to see that you have come back to developing svxlink after a long silence, but by now we have fallen back so far from the head version (and cannot switch a single system due to the remotetrx protocol incompatibility) that I can no longer do quick tests of new functionality. First we have to be convinced that the head version is stable and then we will have to do an en-masse update of systems. Currently it is much too hot for that, here.

sm0svx commented 5 years ago

Yes, updated again: 0ea6db972e2fdba0f87d2cca6f84cca7eaa27e06. It now opens the audio device when the tx/rx object is created.

I'll close this issue for now. Just reopen it if it still does not work when you get time/temperature to test it.