Portaudio has a built-in loop that you are mostly stuck with. It makes things
much easier for the programmer at the expense of flexibility. For this reason I
chose to use native sound drivers on freedv-server. Using separate clock
sources is indeed a problem and pretty much everyone will have it. Real
recording studios use house clock (like house sync in a TV studio) and
expensive sound cards with external clock inputs.
So far, I have implemented ALSA, and there is a lot of code about underrun and
the clock difference. In some cases I stuff silence into the output to keep it
enough samples ahead of the input. This will happen when the program starts and
if it is suspended and resumed, and after a long-running program suffers clock
differences, but it should not happen in normal operation unless you have a bad
crystal in one sound interface. I check the delay on both input and output, and
flush the buffer if the delay gets too long. This will happen if the program is
suspended.
I lock down RAM and set up real-time scheduling, and there is code to tell the
user how to set the correct privileges to do those things.
On March 27, 2014 3:14:49 AM PDT, Stephen Hurd <[email protected]> wrote:
>The next thing I plan on working on in FreeDV will be the artificial
>"one sound card"/"two sound card" stuff and the two full-duplex stream
>thing.
>
>On my current main system, my headset is actually connected to two
>different sound interfaces... the mic is on a separate sound card than
>the phones. For whatever reason, Portaudio truly hates this
>configuration - likely because having two separate clock sources on a
>full-duplex stream will result in weird artefacts. However, since the
>use case isn't actually a full duplex stream but two pairs of isolated
>half duplex ones (mic in/radio out, radio in/headset out), there's no
>technical reason to have these paired into a "headset" full duplex
>stream and a "radio" full duplex stream that I can think of. The
>obvious solution is to split these into four separate configurations
>and
>streams. The configuration dialogue box could easily stay the same,
>and
>for backward compatibility, the config file could as well (though I'm
>not a huge fan of the audio config dialogue, so it's on my radar).
>
>What I'm wondering is if the current two full-duplex stream was
>originally done for technical reasons I'm unaware of (for example,
>maybe
>Portaudio doesn't support multiple streams on the same device) or if
>it's just a reflection of the "you need two sound cards" thought
>process? If the former, it would still be possible (but more complex)
>to share a full-duplex stream when it's detected that the same device
>is
>being used in both directions. I can't find any solid statement either
>
>way in the Portaudio documentation, but I've had experiences with the
>OSS API which suggests this may be so. What's even worse is that it's
>likely that *if* there's a technical limitation, it would quite
>possibly
>only occur with some specific set of soundcards on some set of
>platforms
>with some set of drivers. Something that is very hard to get good test
>
>coverage of in a volunteer project without alienating users.
>
>If anyone remembers the reasoning behind this choice, and it's just a
>conceptual thing, it would make it possible for me to do the much
>simpler implementation. However, if nobody remembers, or if it's a
>technical reason, I'll go ahead and start working with full duplex
>streams when possible and half duplex streams otherwise.
>
>Thanks in advance for your feedback,
>K6BSD
>
>------------------------------------------------------------------------------
>_______________________________________________
>Freetel-codec2 mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/freetel-codec2
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
