Re: [9fans] read/write offset hack

Re: [9fans] read/write offset hack

[erik quanstrom]

> P. P. S.  The usb audio use of offsets is not as bad as it first sounds.
> The device consumes written data at a constant rate (say, 176,400
> bytes per second for CD audio).  You can make a noise ten seconds
> from now by writing 1.7MB bytes of zeros (silence) followed by your
> sound data.  Being able to seek ahead 1.7MB instead just avoids the
> need to write the zeros.  The file offset is still bytes, not nanoseconds.
>

why not put the timing information inband?  this would allow the timed
sound to be saved to a file also without 1.7mb of zeros.

- erik

Re: [9fans] read/write offset hack

[roger peppe]

On Fri, May 30, 2008 at 4:15 PM, erik quanstrom <quanstro@coraid.com> wrote:
> why not put the timing information inband?  this would allow the timed
> sound to be saved to a file also without 1.7mb of zeros.

because then you'd need to quote the audio data in case it
contained something that looked like a timing command?

Re: [9fans] read/write offset hack

[Russ Cox]

> why not put the timing information inband?  this would allow the timed
> sound to be saved to a file also without 1.7mb of zeros.

The Plan 9 audio device data format is stereo, 16-bit
little-endian PCM samples.  Given that convention, my
point was only that seeking in that kind of data stream
does make a little bit of sense.  The whole mail was
about the power of working within and respecting
existing conventions, not about redesigning the audio device.

Others might choose different conventions in different situations.
For example, I believe Nemo's Plan B audio device accepts
MP3 format audio to reduce bandwidth requirements for
sending audio to devices elsewhere on the network.
The Plan 9 audio format has the benefit of being close to
the native format for most hardware.

As always, your own context dictates whether or not
breaking established conventions is a good idea.  Of course,
the Sparc /dev/audio is not just a good idea: it's μ-law.

Russ

[9fans] /dev/audio format (was: read/write offset hack)

[a]

// The Plan 9 audio device data format is stereo, 16-bit
// little-endian PCM samples.

While I was at the labs, I'm pretty sure we had a /dev/audio that could
take different audio formats (told the format via /dev/audioctl). I can't
remember where it came from, though. Was something like this ever in
Brazil, or was this specific to our group (Mesa; Geoff?)? I believe it was
limited to things like PCM, μ-law, and friends, at different combinations
of stereo, mono, and bitrates, not anthing as complex as mp3.

Mostly just trying to fill in a memory gap.
Anthony

Re: [9fans] /dev/audio format (was: read/write offset hack)

[geoff]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

The devaudio Anthony remembers was in the Brazil kernel maintained by
the Mesa group and appears to have come from some Inferno BU kernel.
It supported exactly PCM, μ-law and a-law.

The current Inferno audio(3) claims to support "ulaw, alaw, pcm, pcm16
or adpcm".

[-- Attachment #2: Type: message/rfc822, Size: 2334 bytes --]

From: a@9srv.net
To: 9fans@9fans.net
Subject: [9fans] /dev/audio format (was: read/write offset hack)
Date: Fri, 30 May 2008 15:11:35 -0400
Message-ID: <3131a8932bcc91ca2802ea9d02a40c75@9srv.net>

// The Plan 9 audio device data format is stereo, 16-bit
// little-endian PCM samples.

While I was at the labs, I'm pretty sure we had a /dev/audio that could
take different audio formats (told the format via /dev/audioctl). I can't
remember where it came from, though. Was something like this ever in
Brazil, or was this specific to our group (Mesa; Geoff?)? I believe it was
limited to things like PCM, μ-law, and friends, at different combinations
of stereo, mono, and bitrates, not anthing as complex as mp3.

Mostly just trying to fill in a memory gap.
Anthony

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Charles Forsyth]

> The current Inferno audio(3) claims to support "ulaw, alaw, pcm, pcm16
> or adpcm".

if the device supports it.  reading the ctl file reveals available formats.

Re: [9fans] /dev/audio format (was: read/write offset hack)

[erik quanstrom]

> The devaudio Anthony remembers was in the Brazil kernel maintained by
> the Mesa group and appears to have come from some Inferno BU kernel.
> It supported exactly PCM, μ-law and a-law.
>
> The current Inferno audio(3) claims to support "ulaw, alaw, pcm, pcm16
> or adpcm".

a search on "inferno bu" turns up this

	http://cgi.ebay.com/3Racing-Rear-Anti-Roll-Bar-for-Kyosho-Mini-Inferno-BU_W0QQitemZ160244218723QQcmdZViewItem?IMSfp=TL0805280137r6123

does anyone have any ptrs or information about either of the aforementioned?

- erik

Re: [9fans] /dev/audio format (was: read/write offset hack)

[andrey mirtchovski]

BU is the "Business Unit". the reason we're not using Plan 9 and
Inferno instead of Linux and Java ;)

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Skip Tavakkolian]

> BU is the "Business Unit". the reason we're not using Plan 9 and
> Inferno instead of Linux and Java ;)

i don't think their marketing really understood what they had.

on the plus side, M$ is embracing and extending the ideas with their
singularity "innovation".  also, windows7 is coming out soon, and
maybe we'll get to windows9 in 4-6 years; one can hope windows9 would
be like plan9 only gui-er.

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Bruce Ellis]

Correct. There were several generations of audio (and later
multimedia) drivers in both BU Inferno and Research Inferno. e.g. the
Windows driver supports any installed codec.

There was also the Inferno Audio File format which was rather fb like.
The file began with text lines describing the stuff and then after a
\n\n the rest was data. (The drivers didn't know the format, the
player and other tools did.)

An unofficial history of Inferno would be amusing. Maybe it'll be
penned up in a bar at a future IWP9. ericvh was lucky enough to have
been in the /dev/caveman meeting. The "third party fools" era was
entertaining too, though very sad.

brucee

On 5/31/08, geoff@plan9.bell-labs.com <geoff@plan9.bell-labs.com> wrote:
> The devaudio Anthony remembers was in the Brazil kernel maintained by
> the Mesa group and appears to have come from some Inferno BU kernel.
> It supported exactly PCM, μ-law and a-law.

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Bruce Ellis]

Sorry if you were eating dinner.

On 5/31/08, Charles Forsyth <forsyth@terzarima.net> wrote:
> > The "third party fools" era was
> > entertaining too, though very sad.
>
> don't remind me.

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Charles Forsyth]

> The "third party fools" era was
> entertaining too, though very sad.

don't remind me.

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Enrico Weigelt]

* Bruce Ellis <bruce.ellis@gmail.com> wrote:

Hi,

> There was also the Inferno Audio File format which was rather fb
> like.The file began with text lines describing the stuff and then
> after a\n\n the rest was data.

Interesting idea.
We could also use something like HTTP or mail headers - easy to
understand for many people :)

Maybe an advanced audio server could even directly understand
mimetypes ? ,-O

BTW: some weeks ago, I started hacking on an 9P'ed pulseaudio.
It will be configurable completely via 9P and also support
audio I/O via 9P. But I'm still looking for a suitable interface.

The audio interface should be capable of completely replacing
other common interfaces (in GNU world), so eg. understand
all hw-supported formats, realtime-capable, etc.

Once this works, I intend to rewrite certain client libs for
other audio servers (pulse, esd, arts, ...) to go through
that new 9P interface.


Suggestions appreciated :)


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] /dev/audio format (was: read/write offset hack)

[Bruce Ellis]

mime type of x-iaf was used successfully.

On 6/1/08, Enrico Weigelt <weigelt@metux.de> wrote:
> * Bruce Ellis <bruce.ellis@gmail.com> wrote:
>
> Hi,
>
> > There was also the Inferno Audio File format which was rather fb
> > like.The file began with text lines describing the stuff and then
> > after a\n\n the rest was data.
>
> Interesting idea.
> We could also use something like HTTP or mail headers - easy to
> understand for many people :)
>
> Maybe an advanced audio server could even directly understand
> mimetypes ? ,-O
>
> BTW: some weeks ago, I started hacking on an 9P'ed pulseaudio.
> It will be configurable completely via 9P and also support
> audio I/O via 9P. But I'm still looking for a suitable interface.
>
> The audio interface should be capable of completely replacing
> other common interfaces (in GNU world), so eg. understand
> all hw-supported formats, realtime-capable, etc.
>
> Once this works, I intend to rewrite certain client libs for
> other audio servers (pulse, esd, arts, ...) to go through
> that new 9P interface.
>
>
> Suggestions appreciated :)
>
>
> cu
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
>
>