Flogging this horse still
But as I got my old Edirol UA-3d working with plan9 again (i.e. I
plugged it in!) I thought I'd see what the USB audio landscape looked
like, my it has changed.
Has anyone tried one of these with plan9
http://www.roland.com/products/en/UA-101/
It also does MIDI whi
Thanks, very interesting read.
I think he lied, he was perfectly aware of how the piracy issue would
turn out, and he had it all planned :D
On Fri, Aug 14, 2009 at 11:54 PM, Skip Tavakkolian<9...@9netics.com> wrote:
> an old interview with some relevance
>
> http://www.wired.com/wired/archive/3.0
Ok, My memory from about 1982...
first there was phillips who used 2 high speed, high linearity 14bit DACs
in their CD players using 4 times oversampling - as they had no apropriate
16bit converters at the time; which gives near 16bit resolution.
sony however developed a laser trimmed 16bit conve
> Personally I can't hear over 9119 hz (audio), but I might want to record
> 1s of 192Khz (samples I presume) and stretch them by 100x to 9600 hz
> (audio) and have a (possibly) interesting time listening to the results
> without interpolating.
perfect customer for the Phone Company! ☺
- erik
On Sat, 15 Aug 2009 05:24:01 +0800 sqweek wrote:
> On 12/08/2009, Tim Newsham wrote:
> > Draw the line at what the hardware can be told to decode
> > with a flip of a register? The driver interface can easily
> > accomodate arbitrary encoding names (see inferno's driver
> > for an example).
>
an old interview with some relevance
http://www.wired.com/wired/archive/3.08/thompson.html
On 12/08/2009, Tim Newsham wrote:
> Draw the line at what the hardware can be told to decode
> with a flip of a register? The driver interface can easily
> accomodate arbitrary encoding names (see inferno's driver
> for an example).
One thing I haven't seen mentioned (perhaps because I misunder
Charles Forsyth wrote:
> sorry, i did realise. i'm afraid i just couldn't resist slightly
> misquoting Flanders and Swann's `Song of Reproduction' (High Fidelity).
> http://www.amazon.com/Complete-Flanders-Swann-Georges-Brassens/dp/B06T4S/ref=pd_sim_b_1
Yes, marketing in general feeds on "more
By this logic, I need to have my application to convert CDROM-XA ADPCM
audio from a device into PCM just to talk to an interface, which in turn
must convert it back into ADPCM to play it back because the DMA
transfers to the audio hardware buffer require ADPCM.
the problem with supporting everyt
2009/8/14 James Tomaschke :
> Devon H. O'Dell wrote:
>> If hardware is 2...@192, #A is 2...@192
>
> I am not aware that #A allows for 24bit samples, I only see an option
> "speed" to set sampling rates. The man page says: "Each sample is a 16
> bit little-endian two's complement integer".
>
> I wa
I think I can consider myself lucky, that my equipment doesn't know
how to do AC-3 or DTS :)
Although my soundcard does have some other interfaces i.e. for a
S/PDIF clock source.
On Fri, Aug 14, 2009 at 4:45 AM, Roman V. Shaposhnik wrote:
> On Wed, 2009-08-12 at 17:36 +0200, hiro wrote:
>> > This
> If you're recording doing it at 24-bit will pay off in the mixing
> stage.
Thanks. And there can be some other kinds of stages, too.
Charles Forsyth wrote:
Hardware 24...@192khz.
the human ear can't hear as high as that
still, it ought to please any passing bat!
Hi-fi, hi-fi, ...
Personally I can't hear over 9119 hz (audio), but I might want to record
1s of 192Khz (samples I presume) and stretch them by 100x to 96
fors...@terzarima.net (Charles Forsyth) writes:
>>Hardware 24...@192khz.
>
> the human ear can't hear as high as that
> still, it ought to please any passing bat!
> Hi-fi, hi-fi, ...
If you're recording doing it at 24-bit will pay off in the mixing
stage.
sorry, i did realise. i'm afraid i just couldn't resist slightly
misquoting Flanders and Swann's `Song of Reproduction' (High Fidelity).
http://www.amazon.com/Complete-Flanders-Swann-Georges-Brassens/dp/B06T4S/ref=pd_sim_b_1--- Begin Message ---
Charles Forsyth wrote:
>> Hardware 24...@192khz.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Devon H. O'Dell wrote:
> This is starting to remind me of two things:
>
> 1) The case where this guy did a review of two different audio
> processors, and labeled the DAC of one as inferior to the other. He
> posted audio files of the resulting output
Devon H. O'Dell wrote:
> If hardware is 2...@192, #A is 2...@192
I am not aware that #A allows for 24bit samples, I only see an option
"speed" to set sampling rates. The man page says: "Each sample is a 16
bit little-endian two's complement integer".
I was only going by what the manpage said, pe
This is starting to remind me of two things:
1) The case where this guy did a review of two different audio
processors, and labeled the DAC of one as inferior to the other. He
posted audio files of the resulting output from one and the other.
Except he posted the exact same link for both of them.
2009/8/13 James Tomaschke :
> Devon H. O'Dell wrote:
>> 2009/8/13 James Tomaschke :
>>> Rather, your suggestion of forcing a single format, prevents my
>>> applications from using other formats, and it requires I implement
>>> conversions. This is because you limit freedom by placing a simple
>>>
Charles Forsyth wrote:
>> Hardware 24...@192khz.
>
> the human ear can't hear as high as that
> still, it ought to please any passing bat!
> Hi-fi, hi-fi, ...
So if i instead said 24...@44.1khz would it make any difference on my
argument? please.
You are right, however 192kHz means the DAC bandw
>Hardware 24...@192khz.
the human ear can't hear as high as that
still, it ought to please any passing bat!
Hi-fi, hi-fi, ...
On Wed, 2009-08-12 at 17:36 +0200, hiro wrote:
> > This sounds like exactly the kind of thing one wants
> > from an audio driver for playback. For recording things
> > get slightly more complicated.
>
> What exactly do you mean?
Now that I understand what Tim is trying to do my original
concern m
Anthony Sorace wrote:
> James Tomaschke wrote:
>
> // ...you limit freedom by placing a simple interface into kernelspace.
>
> are you serious?
Show me how forcing a single sample format on the user increases their
freedom in developing audio applications.
Devon H. O'Dell wrote:
> 2009/8/13 James Tomaschke :
>> Rather, your suggestion of forcing a single format, prevents my
>> applications from using other formats, and it requires I implement
>> conversions. This is because you limit freedom by placing a simple
>> interface into kernelspace.
>
> Th
2009/8/13 Devon H. O'Dell :
> 2009/8/13 James Tomaschke :
>> Rather, your suggestion of forcing a single format, prevents my
>> applications from using other formats, and it requires I implement
>> conversions. This is because you limit freedom by placing a simple
>> interface into kernelspace.
>
2009/8/13 James Tomaschke :
> erik quanstrom wrote:
>
>>> I don't see the complexity, the interface merely needs to allow device
>>> drivers to provide the information such as "I support x y z", the
>>> application can query a "features" file, select a format and write back
>>> through the interfac
James Tomaschke wrote:
// ...you limit freedom by placing a simple interface into kernelspace.
are you serious?
erik quanstrom wrote:
>> I don't see the complexity, the interface merely needs to allow device
>> drivers to provide the information such as "I support x y z", the
>> application can query a "features" file, select a format and write back
>> through the interface configuring the hardware. The in
> However if you are instead suggesting that it will take time to support
> other formats other than signed 16-bit little-endian samples. I have no
> problem with a driver developer initially starting there leaving it
> incomplete. At least someone has the potential to add such support.
i don't
erik quanstrom wrote:
>>> My list was only there to try and prove the point that Russ has
>>> made -- pick a most common format and stick with it. Convert
>>> everything else into it.
>> By this logic, I need to have my application to convert CDROM-XA ADPCM
>> audio from a device into PCM just to t
On Thu, Aug 13, 2009 at 15:52, erik quanstrom wrote:
>> > My list was only there to try and prove the point that Russ has
>> > made -- pick a most common format and stick with it. Convert
>> > everything else into it.
>> By this logic, I need to have my application to convert CDROM-XA ADPCM
>> audi
> > My list was only there to try and prove the point that Russ has
> > made -- pick a most common format and stick with it. Convert
> > everything else into it.
> By this logic, I need to have my application to convert CDROM-XA ADPCM
> audio from a device into PCM just to talk to an interface, whi
Roman Shaposhnik wrote:
> On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote:
>>> Here's a complete list of audio formats that one can make hardware
>>> either generate or accept. Where do you draw the line?
This is incorrect, you don't "make hardware" do anything, the software
layer that sits on top o
Been reading the thread with interest, and I finally have a moment to comment.
I was thinking about this several years ago when I had a lot of spare
time on my hands and wanted to rethink and update the audio interface,
and I think a lot of what you are suggesting sounds similar to the
conclusions
> The Rock and Roll Hall of Fame has a Guitar Hero set up in the
> lobby, but you need to bring your own headphones. I didn't have
> any on me, so tried playing by sight only. It went really poorly.
Our visual perception is very unreliable, whereas our acoustic timing
can be very accurate.
2009/8/12 Tim Newsham :
- What software exists for each of these formats?
>>
>> If you are asking about non Plan9 software I'd start with
>> ffmpeg.
>>
- Which format is the most "popular"?
>>
>> I don't think I understand the question.
>
> Sorry, let me rephrase:
> - Of the different au
2009/8/13 Anthony Sorace :
> Devon H. O'Dell wrote:
> // This is easily demonstrable with rhythm games (such as Rock
> // Band or Guitar Hero) where latency induced by a home audio
> // system (mine at home is about 15ms induced by my receiver
> // and 5ms using the Xbox digital output) can have a
Devon H. O'Dell wrote:
// This is easily demonstrable with rhythm games (such as Rock
// Band or Guitar Hero) where latency induced by a home audio
// system (mine at home is about 15ms induced by my receiver
// and 5ms using the Xbox digital output) can have a very
// significant negative impact o
2009/8/13 erik quanstrom :
> On Thu Aug 13 02:43:54 EDT 2009, 9...@9netics.com wrote:
>> > I'm not sure either latency or RT is proper terminology here. But
>> > I believe what I meant was clear: when you need overall latency
>> > to be around 5ms you start to notice 9P.
>
> when you need the overa
>> it needs to be isochronous.
>
> i believe it has that capability. just keep multiple tags
> outstanding.
at the device it needs to be isochronous; so if it's going over the
wire, you need to build some elasticity in.
or as media players would say: [ buffering... buffering... ] ☺
On Thu Aug 13 02:43:54 EDT 2009, 9...@9netics.com wrote:
> > I'm not sure either latency or RT is proper terminology here. But
> > I believe what I meant was clear: when you need overall latency
> > to be around 5ms you start to notice 9P.
when you need the overall latency to be around 5ms,
aren't
> but I argue it's exactly right.
> PCM is the native hardware sample format and is
> basically the "uncompress bitmap" of the audio world.
makes perfect sense.
> I'm not sure either latency or RT is proper terminology here. But
> I believe what I meant was clear: when you need overall latency
> to be around 5ms you start to notice 9P.
it needs to be isochronous.
- What software exists for each of these formats?
If you are asking about non Plan9 software I'd start with
ffmpeg.
- Which format is the most "popular"?
I don't think I understand the question.
Sorry, let me rephrase:
- Of the different audio driver interface designs
(audio(3), usb(4
> I don't think I buy this point of view. Gratuitous flexibility is not
> something Plan 9 is known for, nor should it. IMHO.
those with such talents don't generally enjoy a good reputation.
but i hear they make great money on the internet.
- erik
On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote:
I agree wrt. "mp3". I'm considering the possibility of supporting
alaw, ulaw, pcm8, pcm16 in big/little and signed/unsigned formats,
and adpcm, using the hardware features...
Here's a complete list of audio formats that one can make hardware
eit
On Aug 12, 2009, at 12:50 PM, Tim Newsham wrote:
Still would love to hear if anyone knows the answer to these:
- What software exists for each of these formats?
If you are asking about non Plan9 software I'd start with
ffmpeg.
- Which format is the most "popular"?
I don't think I underst
On Aug 12, 2009, at 4:18 AM, erik quanstrom wrote:
In fact, perhaps even the page(1) command is falwed. What should've
happened was a next layer over rio, where /dev/draw/n/data would
be able to accept any kind of image encoding.
i think page is a good thing. pushing data
translation to the ed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russ Cox wrote:
> I've done audio on a handful of operating systems
> and all I ever want to do with the card is set it up
> to play X kHz 16-bit little-endian PCM stereo and
> then control the volume. The rest can be done from
> user space. This is
On Wed, 12 Aug 2009 09:50:13 -1000 Tim Newsham wrote:
> Still would love to hear if anyone knows the answer to these:
>
> > - What software exists for each of these formats?
Are you asking about non p9 software? If so, have you looked
at SoX (Sound eXchange)? It is sort of like netpbm but for
a
Still would love to hear if anyone knows the answer to these:
- What software exists for each of these formats?
- Which format is the most "popular"?
Tim Newsham
http://www.thenewsh.com/~newsham/
On Tue, Aug 11, 2009 at 10:10 PM, Tim Newsham wrote:
> I'm not sure either latency or RT is proper terminology here. But
>> I believe what I meant was clear: when you need overall latency
>> to be around 5ms you start to notice 9P.
>>
>
> It sounds like you have a specific app in mind, and a real
> This sounds like exactly the kind of thing one wants
> from an audio driver for playback. For recording things
> get slightly more complicated.
What exactly do you mean?
> Even for playback if you want to do passthrough (via
> SPDIF or some such) things get slightly more complicated.
> Of cours
> 9p is a ping-pong protocol. this gives it *consistent* latency.
> this is good for audio.
Some years ago when I set up the audio stuff in my house I had to
solve the task of streaming the output from mpd (a linux audio player)
running on my file server to the sound card in my room. I couldn't
f
On Tue, Aug 11, 2009 at 9:35 PM, Charles Forsyth wrote:
>> ... Inferno's implementation of mp3 in the kernel device file ...
>
> it does?
sorry, i got my wires crossed.
it was plan b that did that.
russ
> In fact, perhaps even the page(1) command is falwed. What should've
> happened was a next layer over rio, where /dev/draw/n/data would
> be able to accept any kind of image encoding.
i think page is a good thing. pushing data
translation to the edges makes programs like
resample much simplier.
Here is how I think it would work - please correct me if
I am wrong.
the status file gives a list for the supported
features and the current state of each. If particular
hardware does not support mu-law then no state is displayed
for it and the application layer can decide to emulate a
mu-law tabl
I agree wrt. "mp3". I'm considering the possibility of supporting
alaw, ulaw, pcm8, pcm16 in big/little and signed/unsigned formats,
and adpcm, using the hardware features...
Here's a complete list of audio formats that one can make hardware
either generate or accept. Where do you draw the lin
On Aug 11, 2009, at 10:54 PM, Lawrence E. Bakst wrote:
3. video (when I say video I mean movies and not graphics)
If you think you are ever going to want to use your new audio system
with a corresponding video system, you need to consider that from
the outset. Audio and video need to be kept
On Aug 11, 2009, at 10:59 PM, Roman Shaposhnik wrote:
With multichannel playback you have those two options:
1. drive each channel separately with PCM
2. do AC-3/DTC/MP3 passthrough
Meant to include a URL for the curious ones (was trigger-happy):
http://www.mplayerhq.hu/DOCS/tech/hwac
On Aug 11, 2009, at 10:43 PM, Anthony Sorace wrote:
Tim Newsham wrote:
// Yah, this format doesnt come up that often.. perhaps its not
// worth the effort, but then again the ability to switch a device's
// encoding isnt very much work either... About as hard as
// changing the sampling rate or
You really have to ask yourself what are the goals for a new audio system and
what "use cases" do you want to cover. I have some experience in this area, but
I'm not a true expert. Here are 5 thoughts to be considered and an anecdote:
1. audio
I thought Russ's response was pretty good and about
Tim Newsham wrote:
// Yah, this format doesnt come up that often.. perhaps its not
// worth the effort, but then again the ability to switch a device's
// encoding isnt very much work either... About as hard as
// changing the sampling rate or turning stereo on and off...
i'd argue that the prim
On Aug 11, 2009, at 10:15 PM, Tim Newsham wrote:
The simplicity is definitely attractive in its own right,
and I'll consider it. However, the devices do provide hardware
support for other formats which do require some work to convert.
mu-law and a-law come to mind..
In all my life doing multim
On Aug 11, 2009, at 10:10 PM, Tim Newsham wrote:
I'm not sure either latency or RT is proper terminology here. But
I believe what I meant was clear: when you need overall latency
to be around 5ms you start to notice 9P.
It sounds like you have a specific app in mind, and a real-time
one at that
i think russ has it exactly right: keep the kernel driver as simple as
is practical, do whatever else you want in user space. for /dev/audio,
i wouldn't suggest anything beyond plan 9's audio(3) as is. i'd
suggest some cleanup of the surround (kill /dev/volume, rationalize
/dev/audioctl), but the f
I've done audio on a handful of operating systems
and all I ever want to do with the card is set it up
to play X kHz 16-bit little-endian PCM stereo and
then control the volume. The rest can be done from
user space. This is exactly what Plan 9's audio
driver already does, and I wish the others w
I'm not sure either latency or RT is proper terminology here. But
I believe what I meant was clear: when you need overall latency
to be around 5ms you start to notice 9P.
It sounds like you have a specific app in mind, and a real-time
one at that. If you're using your audio device for live audi
On Aug 11, 2009, at 9:25 PM, erik quanstrom wrote:
May be its better to call this latency, since we can all appreciate
some of the shortcomings that 9P has when it comes to it.
i think you're drawing the wrong conclusion from a too-abstract
view of the facts.
My ears begged to differ ;-)
9p
>we have scsi and ata.
>and that's enough for me.
that's more than enough for me.
On Aug 11, 2009, at 9:24 PM, Russ Cox wrote:
It's hard to do the low-level hardware stuff outside
the kernel. It's possible, but it's a lot easier inside.
Just keep the inside simple.
I've done audio on a handful of operating systems
and all I ever want to do with the card is set it up
to play
> ... Inferno's implementation of mp3 in the kernel device file ...
it does?
> May be its better to call this latency, since we can all appreciate
> some of the shortcomings that 9P has when it comes to it.
i think you're drawing the wrong conclusion from a too-abstract
view of the facts.
9p is a ping-pong protocol. this gives it *consistent* latency.
this is good for au
It's hard to do the low-level hardware stuff outside
the kernel. It's possible, but it's a lot easier inside.
Just keep the inside simple.
I've done audio on a handful of operating systems
and all I ever want to do with the card is set it up
to play X kHz 16-bit little-endian PCM stereo and
then
On Aug 11, 2009, at 7:07 PM, Tim Newsham wrote:
i didn't mean translating from one /dev/audio to the next.
i ment dealing with azalia audio vs. ac97 vs. soundblaster.
and ogg/vorbis vs. mp3 vs pem vs. *law.
I agree here. I envision a separate codec server that
sits on top of an audio server an
> It would be nice, I think, to do it out of the kernel ... still better
> to do it in a way that makes it easy to adopt new audio formats
> without having to rip out the guts each time and start over -- which
> seems to be the linux problem.
i'm just glad they don't do this with disks. we have s
It would be nice to do plan 9 audio if only to show people how it can
be done. Anyone who deals with audio on linux knows how not to do it;
but it's probably very hard to get it right. I know I could do no
better.
It would be nice, I think, to do it out of the kernel ... still better
to do it in a
i didn't mean translating from one /dev/audio to the next.
i ment dealing with azalia audio vs. ac97 vs. soundblaster.
and ogg/vorbis vs. mp3 vs pem vs. *law.
I agree here. I envision a separate codec server that
sits on top of an audio server and encapsulates a bunch
of this stuff. It would b
> Instead of writing translators I'd rather pick a single convention
> that seems the most suitable and fixup the other implementations
> and clients to fall in line with those conventions. My biggest
> question is "is it worth my time?" If I spend time unifying
> the various implementations, wil
there are a couple of models for dealing with lots
and lots of standards. there's the tcs/jpg translator
model. but i think the upas/fs model might work better
for audio. you can present a standard menu of resources
and translate on the fly with a fs. might be kind of cool.
Instead of writin
> - Is there any interest in unifying the existing audio formats?
> - If so, is anyone interested in bouncing around ideas of what
>this format should look like?
this is probablly super obvious. but as one as you
pick a cannonical format as is the plan 9 custom
(like for character sets, image
I'm looking over the audio device formats because I would
like to make a service that is interoperable with the existing
services and much to my dismay there are several different
formats:
- plan9 audio(3) with audio,volume,audiostat
- plan9 usb(4) with audio,volume,audioctl,audioin
- in
82 matches
Mail list logo
