Hi all,
Just wanted to share some interesting news with all who are still
waiting to obtain one of these beasts (Hammerfall DSP) and have been
waiting for a long time (like myself).
I just found out from talking to a RME US reseller that Steinberg sells
exactly the same hardware for a lower pric
> ALSA isn't a user space driver.
>
> Its a kernel space driver that comes with a user space library. The
> library has several purposes:
>
> 1) hide hardware specific details that are represented
>at the raw device level (i.e. via /dev/snd/...)
>
> 2) encapsulate comm
> Kernelspace is the worst possible place you can ever do that.
Thank you for your thoughts regarding this issue. Still, you did not
answer the most important part of the question:
why is that so?
Ico
>Since we are talking about this [non]issue, again, I just realized that
>there is one thing I am still not able to comprehend completely, so I
>would greatly appreciate any thoughts on this one.
>
>It is no rocket science to figure out that Alsa is the way to go, and I
>am all for it. But one thi
On Sat, 9 Mar 2002, Ivica Bukvic wrote:
> It is no rocket science to figure out that Alsa is the way to go, and I
> am all for it. But one thing I do not comprehend is why is the
> user-space driver better than the kernel space one?
It is simply 100,000,000 times more flexible than a kernel space
On Sat, 9 Mar 2002 21:13:06 -0500
"Ivica Bukvic" <[EMAIL PROTECTED]> wrote:
> Since we are talking about this [non]issue, again, I just realized that
> there is one thing I am still not able to comprehend completely, so I
> would greatly appreciate any thoughts on this one.
>
> It is no rocket s
Since we are talking about this [non]issue, again, I just realized that
there is one thing I am still not able to comprehend completely, so I
would greatly appreciate any thoughts on this one.
It is no rocket science to figure out that Alsa is the way to go, and I
am all for it. But one thing I d
>They _should_ be in kernel, as SCSI and similar layers are. But I don't
>think format conversions are necessary at all.
So what do you think should happen when someone tries to run
a 16 bit application on hardware that only supports 24-of-32bit samples?
Does every application have to do the conv
>> The problem isn't making chrome easy. It isn't the available
>> widgets. Its the presence of an event loop that is incompatible
>> with another toolkit. At least, thats the problem that I see and
>> was referring to.
[ ... ]
>Anyway, *why* are people doing this "hidden event loop" thing over
>I think accurate MIDI timing eventually comes down on how well the
>operating system performes. If Linux had a better performing nanosleep()
>, i.e. if it would reprogram the clock chip to generate one shot interrupts
>at the exact time the first ready thread will need to be woken up, then
>the M
> > No, it doesn't accomplish this, but it can. The kernel will have to
> > support it, so Linux will have to gain accurate scheduling. In the
> > meantime I think getting the clock resolution on Intel from 10ms
> > down to 1ms will be sufficient in most cases.
>
> How likely is it that this will
>> actually, its easier. it just isn't documented to make it seem that
>> way. the major benefits are that no device-specific hacks are needed
>> and format conversion is handled by alsa-lib. there are others. i
>
>OSS does format conversions. And also does samplerate conversion and
>software mixi
(All of a sudden, I'm becoming interested in high resolution timers
w/ scheduling capabilities in mainstream kernels... but not for
reasons that have much to do with audio.)
On Wednesday 06 March 2002 11.46, Martijn Sipkema wrote:
[...CLOCK_MONOTONIC...]
> No, it doesn't accomplish this, but
> > > Ok, I was of course thinking of timestamping MIDI events with the
> > > "audio clock". No problem when running a sequencer as a part of
> > > the audio network, but it does get messy to timestamp the MIDI
> > > events.
> >
> > I would prefer timestamping MIDI messages with some common clock.
Paul Davis wrote:
>
> QNX too. :)))
True, I've used it, but it supports only 0.5 API.
> actually, its easier. it just isn't documented to make it seem that
> way. the major benefits are that no device-specific hacks are needed
> and format conversion is handled by alsa-lib. there are others. i
On Tuesday 05 March 2002 23.28, Martijn Sipkema wrote:
> > Ok, I was of course thinking of timestamping MIDI events with the
> > "audio clock". No problem when running a sequencer as a part of
> > the audio network, but it does get messy to timestamp the MIDI
> > events.
>
> I would prefer timesta
On Tuesday 05 March 2002 16.10, Paul Davis wrote:
[...]
> >Yeah... The stream frame rate is the clock.
>
> the window/macos worlds have been pretty unhappy with this
> arrangement, which i am convinced is part of the reason for the
> emergence of these newer interfaces which accept pre-queued
> da
On Tuesday 05 March 2002 16.14, Paul Davis wrote:
> >I still think there is, but I'm not so sure it's actually
> > something that can be implemented with a reasonable amount of
> > work. I believe the problem with any new toolkit of the
> > traditional kind is that it would either be too restricti
18 matches
Mail list logo
