* File descriptors and Sound
@ 1999-08-08 23:48 Rui Sousa
1999-08-08 23:53 ` Alan Cox
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Rui Sousa @ 1999-08-08 23:48 UTC (permalink / raw)
To: linux-sound
Hi,
Can someone give me some pointers on how to get control
over /dev/audio by two different applications?
I realized that it's not possible to open /dev/audio
in two separate applications while trying to setup
speakfreely...
If the device is full-duplex how can I have one application
reading it and another writing?
Thanks in advance
--
Rui Sousa
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: File descriptors and Sound
1999-08-08 23:48 File descriptors and Sound Rui Sousa
@ 1999-08-08 23:53 ` Alan Cox
1999-08-09 14:57 ` Rui Sousa
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Alan Cox @ 1999-08-08 23:53 UTC (permalink / raw)
To: linux-sound
> If the device is full-duplex how can I have one application
> reading it and another writing?
You either do file handle passing (funky) or normally one program runs the
other: ie
open file
fork()
child:
exec other app (which inherits file)
exit
parent:
run code
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: File descriptors and Sound
1999-08-08 23:48 File descriptors and Sound Rui Sousa
1999-08-08 23:53 ` Alan Cox
@ 1999-08-09 14:57 ` Rui Sousa
1999-08-09 16:40 ` Matthew Wilcox
1999-08-13 12:41 ` Benno Senoner
3 siblings, 0 replies; 5+ messages in thread
From: Rui Sousa @ 1999-08-09 14:57 UTC (permalink / raw)
To: linux-sound
Alan Cox wrote:
>
> > If the device is full-duplex how can I have one application
> > reading it and another writing?
>
> You either do file handle passing (funky) or normally one program runs the
> other: ie
>
> open file
> fork()
>
> child:
> exec other app (which inherits file)
> exit
>
> parent:
> run code
As I said before I'm trying to get speakfreely to work in full-duplex
mode.
This program has two components (two independent processes) that try to
access /dev/audio. The thing is that during execution they open/close
/dev/audio multiple times so I think that the second method wont work
(correct me if I am wrong).
Can you indicate me some (online) documentation concerning file handle
passing?
Thanks
--
Rui Sousa
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File descriptors and Sound
1999-08-08 23:48 File descriptors and Sound Rui Sousa
1999-08-08 23:53 ` Alan Cox
1999-08-09 14:57 ` Rui Sousa
@ 1999-08-09 16:40 ` Matthew Wilcox
1999-08-13 12:41 ` Benno Senoner
3 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 1999-08-09 16:40 UTC (permalink / raw)
To: linux-sound
On Mon, Aug 09, 1999 at 03:57:08PM +0100, Rui Sousa wrote:
> Can you indicate me some (online) documentation concerning file handle
> passing?
man 7 unix in very recent manpage distributions (formerly part of netman).
--
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: File descriptors and Sound
1999-08-08 23:48 File descriptors and Sound Rui Sousa
` (2 preceding siblings ...)
1999-08-09 16:40 ` Matthew Wilcox
@ 1999-08-13 12:41 ` Benno Senoner
3 siblings, 0 replies; 5+ messages in thread
From: Benno Senoner @ 1999-08-13 12:41 UTC (permalink / raw)
To: linux-sound
On Mon, 09 Aug 1999, Alan Cox wrote:
> > If the device is full-duplex how can I have one application
> > reading it and another writing?
>
> You either do file handle passing (funky) or normally one program runs the
> other: ie
>
> open file
> fork()
>
> child:
> exec other app (which inherits file)
> exit
>
> parent:
> run code
ok,
but what if one wants to implement some sort of MIDI-thru util ?
(not related to /dev/audio but /dev/midi , but the problem is the same:
2 different apps want to access to the same device,
the one in O_RDONLY , the other in O_WRONLY mode)
For example:
/dev/midi00 external midi port
/dev/midi01 AWE64 internal synth
Assume the midi-thru util opens /dev/midi00 in O_RDONLY and /dev/midi01 in
O_WRONLY mode.
The app reads the incoming midi data from the midi00 device and applies certain
event filters and then writes the data to /dev/midi01. (the synth).
It would be nice if a sequencer was still able to to write to /dev/midi00 to
drive an external synth.
Since the sequencer tries to open /dev/midi00
(assuming that the sequencer opens the device only in O_WRONLY mode),
I can't use the fork() method to inherit filehandles.
Is there a way to do this ?
What is in your opinion the best way to implement a virtual midi device in
userspace ? Like the midi-thru example
Using a regular named pipe ?
But sequencers would not recognize this virtual device since they look in
/dev/sndstat for available devices.
regards,
Benno.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-08-13 12:41 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1999-08-08 23:48 File descriptors and Sound Rui Sousa
1999-08-08 23:53 ` Alan Cox
1999-08-09 14:57 ` Rui Sousa
1999-08-09 16:40 ` Matthew Wilcox
1999-08-13 12:41 ` Benno Senoner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox