Re: Piping audio from Linrad to other applications?

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

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?

73

Leif / SM5BSZ


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL