[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Piping audio from Linrad to other applications?

Hi Leif,

On Fri, 2008-02-15 at 11:38 +0100, Leif Asbrink wrote:
> On Thu, 14 Feb 2008 17:28:22 -0800 (PST)
> nh7o <nh7o@xxxxxxxxxxxx> wrote:
> > One last comment:
> > 
> > I found that there is an easy way for ALSA native applications to use
> > JACK without any changes using the ALSA plugin library. But it is no
> > go with Linrad, even though the OSS compatibility in ALSA is there.
> It was worth trying, I am sorry ir failed.
> > So it looks like the only way to get Linrad to send audio to other
> > apps is through a rewrite of the sound I/F, making it ALSA based.   
> > :-(
> > 
> > I suspect Leif has better things to do with his precious time than to
> > fix what isn't broken...
> This would be something that someone else might be able to do.
> Linrad has a very simple interface to the hardware, the routines
> are:
> open_rx_sndin()
> open_rx_sndout()
> close_rx_sndin()
> close_rx_sndout()
> Linrad has separate threads, one that hangs on a read statement
> on the A/D input until it returns and another one that uses
> a write statement and hangs on it until there is buffer space.
> There are also timing control functions:
> int lir_rx_output_bytes(void) returning the number of bytes
> remaining until the outbut buffer is full.
> int make_da_wts(void)
> The number of samples written to the buffer but not sent to
> the loudspeaker. Actually it is the same information as the
> previous routine, they differ in that one will try to
> restart the sound system in case it has failed. It was needed
> long ago when sound drivers were a bit unstable, but I do not think
> there is any reason to keep them separate.
> void lir_empty_da_device_buffer(void)
> This function will reset the output and clear the buffer.
> It is needed to remove the data already written to the buffer
> to make the response to a mouse click immediate.
> The six calls to the sound system are implemented for Linux
> legacy sound in lsetad.c and for Windows in wsetad.c. All the
> complexity of these routines relate to the simple text based
> setup routine (U=A/D and D/A setup for rx) than can be accessed
> from the main menu.
> I am sure that someone knowing ALSA could easily write a sample
> program that would investigate the system and allow the user to
> select what device he wants and how he wants to have it opened.
> input or output
> No of bytes per sample
> No of samples per second
> No of channels
> A nice interface that reports the native capacity of the soundcard
> would be fine. Under alsa-oss all cards report the full range of
> the format conversions in software and one can easily waste CPU
> time and performance by needless rate conversions.
> With a simple C program that allows a user to first select
> mode, then open a device, read or write to it once, and for
> output, find the buffer usage and be able to reset it and
> finally close the device I could easily change Linrad to ALSA
> (or perhaps give the user a choice at compile time or even 
> at run time)
> ALSA is C++. I understand nothing of it so I need someone else
> to make a prototype program. Any volunteers?

I will give it a try:

I found a few interesting prototype programs,written in  C,  at 

At this point in time, the conversion of the timing control functions in
linrad seems to be the biggest challenge ( for me at least ;-) )
I will probably need some help from your side  in that area.

Hope to have a workable lsetadalsa.c for the next EME conference.




You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad-unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad