lkml.org 
[lkml]   [1999]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectreading digidal audio (was: which pci sound card does not have dr opouts under load)
Date
BTW: Thanks for the help.

For reading digital audio I use

cdparanoia -w 1 track1.wav

and it does several corrections ( + and - signs are displayed sometimes).
To my knowledge the ecc is done in the CD-Rom drive.

So it seems that jitter corrections are necessary.

Cdparanoia uses special ioctls to read the audio data digitally
from the CD. A simple module providing a /dev/audiocd device (including)
jitter correction would be helpful. then something like

cat /dev/audiocd > /dev/dsp

would be possible. That way the reading of the data would be done
with read() and not with ioctl() (It is IMHO ugly to misuse ioctl for that).

I like the EVERYTHING IS A FILE philosophy of unix.

Before a "Kernel Bloat" diskussion starts: If it is possible to write
a user space program which provides a device that could be done without
a module. Is it possible to use a demon with a named pipe for that?

I imagine the following:
- Demon is started when booting but sleeps.
- When someone opens the device the demon wakes up.
- A user program can use seek() or ioctl() to select a track or place
inside track.
- The user program uses read() to read the audio track.
- The demon uses the ugly read ioctls to read the audio data and does
jitter corrections.
- Another program is not able to open the device as long as it is open.
- The user program closes the device. The demon sleeps aggain.

This user-device philosophy can also be used to provide other devices.
Is this possible? Now, in the future? What changes are necessary to do this?

Greetings Thomas


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.136 / U:0.968 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site