I have a question on the game plan for Windows, Linux and WHY architectures, not individually, but as a whole. I have been following all the discussions but they have not helped me resolve this issue so I guess the only way to find out is to ask.
Having dabbled with both implementations there is something that has now moved high on my wish list. I have my Smalltalk radio talking to both the Windows and the Linux jsdr implementations. However, the way it does so is quite different. For Windows it's a plugin dll and for Linux it talks through named pipes. For Windows I had to move audio processing back in and make a number of other changes to achieve the integration. I would love a single code line for jsdr that had the same interface and the same functionality on all platforms. The key things I would really like are. 1. A unified messaging interface that is not targeted, so that different external interfaces could be mapped on top to expose jsdr to C#, Java, Python, Lisp, Smalltalk or as a web service, raw socket service or WHY in a way that is the most natural for the language/environment. I don't care particularly what the messaging format is as long as it is expressive enough to cope with complex data formats. What I would hate is a completely separate Windows and Linux jsdr that did exactly what each environment required with a hard coded external interface. 2. For audio processing to be part of jsdr on all platforms and use PortAudio on all, rather than PortAudio on Windows and Jack on Linux. This means all management of sound cards, dual cards, VAC and Jack (I assume Jack would be used under PortAudio for routing) would be common. Is anything like this on the roadmap? Is it a load of rubbish and are there reasons why it will never be like this? My worst nightmare at the moment is that I will keep putting effort into redoing my changes to jsdr every time I want to take a new cut. If it is moving in this direction then I am sure I could help in some way. Best 73 Bob (G3UKB) *** Confidentiality Notice *** Proprietary/Confidential Information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply email.
