Hi Stephen, While I understand the current design might not suit you particular configuration, I can't recall this being a problem for any one else.
So I guess I'm wondering, is this a problem worth solving? I wrote to Portaudio code some 18 months ago, but can't recall why we chose two full duplex streams. I don't think it's caused any problems to date. Cheers, David On Thu, 2014-03-27 at 03:14 -0700, Stephen Hurd 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 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
