On Tue, Jun 14, 2005 at 02:20:13AM +0200, Jay Vaughan wrote:
> WHAT OSS guys,
The guys that wrote it.
http://www.opensound.com/
--
Paul Winkler
http://www.slinkp.com
On Tue, 2005-06-14 at 02:20 +0200, Jay Vaughan wrote:
> yeah, and this sucks ass. to multitrack, depending on my app, i
> could go one of 3 different ways
How is that any different than on Windows where you have to deal with
ASIO, GSIF, WDM, DirectSound, and whatever the hell else? AFAICT only
Lee Revell wrote:
> On Fri, 2005-06-10 at 11:12 -0700, Ian wrote:
> > Can anyone tell me *very briefly* what is the current
> > state of play regarding realtime-lsm in the 2.6.*
> > kernels and whether this feature (or something like it
> > ) is likely to be introduced into the kernel anytime
> > s
what i meant was that there has been dramatically insufficient attention
paid to the development of ALSA tools and/or APIs that provide the kind
of functionality that desktop users want.
man, never forget that you live surrrounded quite literally by tens
of millions of people. your early succ
An API becomes 'official' ... when its uses but most of the
developers. Remember the old days of OS9 when the 'official' MIDI
API was Opcode OMS when MidiShare was already in the field. The
official is not always the 'best' one, but the one pushed by
powerful people... and/or at the right time
Maybe it will be possible to add an interface to ALSA so users
can easily contribute card/computer specific mixer
information. But still there will be some disadvantages:
look, just a lib.so or a class which is capable of parsing a
/usr/src/linux/.config file, working out what the currently-in
right. so we've already established that the actual nature of the
problem on linux is different, and much closer to the windows situation
- a huge variation in hardware types and configurations. jwz solved his
"problem" by throwing the problem away, and moving into a domain where
the problem he ha
That's not a problem, that's the usual evolution as seen may
times in the free software world.
free software is one thing, but free software developers making value
off of working installations is another thing.
'free software' doesn't just mean 'not caring how its used'.
The problem is t
Actually, I find it difficult to find anything in ALSA to confirm the idea
that the requirements from the pro-audio users have had a negative impact
on the system as a whole.
well, even after all-years use of Linux, and many, many years worth
of audio hacking, i don't personally see ALSA as go
You're right. On OSX the MidiShare interrupt source can be derived
from the audio timing, so that the MidiShare time will not drift
form the audio time in case an application has special needs of Midi
+ audio synchronization. A timer only mode is also available.
well, see .. to me .. MIDI prec
> what i meant was that there has been dramatically
> insufficient attention paid to the development of ALSA
> tools and/or APIs that provide the kind of functionality
> that desktop users want. it has been put off and put off as
> the other parts of ALSA have evolved, and now we have a
> really v
> Now the main problem I see with ALSA for the 'desktop'
> users are in the control interfaces. Maybe the idea of the
> driver providing a sort of description of the card (e.g. a
> list of control elements) and having this info interpreted
> by a generic mixer application was not the best one. It
On Mon, 2005-06-13 at 23:30 +0200, Christoph Eckert wrote:
> > the competing APIs is definitely a problem. the OSS guys
> > continue to refuse to accept ALSA, and continue to promote
> > the benefits of their API and libraries. The layers that
> > have been built on top of them (PortAudio, JACK, th
> the competing APIs is definitely a problem. the OSS guys
> continue to refuse to accept ALSA, and continue to promote
> the benefits of their API and libraries. The layers that
> have been built on top of them (PortAudio, JACK, the arts
> audio api, gnome-sound, etc) continue to compete with eac
On Tue, Jun 14, 2005 at 06:46:03AM +1000, Erik de Castro Lopo wrote:
> Yes, but if you meaure the SNR the way I do, you are also
> ensuring the absence of bugs in the implementation of the
> algorithm. As you are probably aware, looking at code is
> not the best way to find bugs in the implementa
Alfons Adriaensen wrote:
> On Mon, Jun 13, 2005 at 10:49:38PM +1000, Erik de Castro Lopo wrote:
>
> > The SNR and bandwith cannot be determined by reading code.
> > Measurement is the only option.
>
> It's perfectly possible to calculate this, and it isn't even
> very difficult. In the case of
Erik de Castro Lopo wrote:
Firstly I see that its basically a drum machine. Drum hits are
relatively we behaved when linear sample rate converison is used.
It looks like a drummmachine, but that's not the goal of the project. I use
vocal, guitar, bass and drum tracks. I know a Jackbeat user wh
thing is though: he does have a point. why is this stuff still so
hard, after so many years? its -not- the drivers, imho, its the
moving-target nature of ALSA and all the competing audio API's,
underneath a pile of semi-working apps ..
the competing APIs is definitely a problem. the OSS gu
> this doesn't work on Linux. you can't herd sheep^H^H^H^H^Hpenguins
> with a flamethrower.
right. so we've already established that the actual nature of the
problem on linux is different, and much closer to the windows situation
- a huge variation in hardware types and configurations. jwz solv
> Actually, I find it difficult to find anything in ALSA to confirm the idea
> that the requirements from the pro-audio users have had a negative impact
> on the system as a whole.
what i meant was that there has been dramatically insufficient attention
paid to the development of ALSA tools and/
it "just worked" for him on OS X
because Apple pick the audio interface.
yup, and they set the API standard, and they govern the distribution, and ..
this doesn't work on Linux. you can't herd sheep^H^H^H^H^Hpenguins
with a flamethrower.
several people provided
reference SuSE supported h/w
On Mon, Jun 13, 2005 at 11:22:57AM -0400, Paul Davis wrote:
> ALSA's biggest problem was that people like me shaped its design too
> much. I was trying to ensure that ALSA was useful for pro-audio setups,
> and I had little interest in the desktop story. There were no
> (sufficiently) vigorous adv
Le 13 juin 05 à 17:22, Paul Davis a écrit :
what makes an API 'official' under Linux, anyway? in my opinion, the
old maxim, "use what works" applies .. and ALSA has proven to be a
very difficult and annoying thing to get set up and working (witness
jwz' recent terror) .. while MidiShare has
Le 13 juin 05 à 17:05, Jay Vaughan a écrit :
Good to see someone other than Grame' guys try to "push"
MidiShare ((:
well, i'm only pushing because i'm using it, and i can't use ALSA. :)
But Jay, MidiShare cannot help in terms of synchronizing MIDI with
audio at the sample level...
> what makes an API 'official' under Linux, anyway? in my opinion, the
> old maxim, "use what works" applies .. and ALSA has proven to be a
> very difficult and annoying thing to get set up and working (witness
> jwz' recent terror) .. while MidiShare has (for the most part) been
> smooth and
Good to see someone other than Grame' guys try to "push" MidiShare ((:
well, i'm only pushing because i'm using it, and i can't use ALSA. :)
But Jay, MidiShare cannot help in terms of synchronizing MIDI with
audio at the sample level. MidiShare events are 1 millisecond
time stamped.
On Mon, Jun 13, 2005 at 10:49:38PM +1000, Erik de Castro Lopo wrote:
> The SNR and bandwith cannot be determined by reading code.
> Measurement is the only option.
It's perfectly possible to calculate this, and it isn't even
very difficult. In the case of a sinc filter, everything is
determined
Kjetil Svalastog Matheussen wrote:
> I was primarily testing speed, but both libraries where using the sinc
> routine, so...
Yes, but you can design a sinc filter with 10 coefficients and one
with 1. The one with 1 coefficients will have a steeper
transition band and a better signal to n
On Mon, 2005-06-13 at 14:00 +0200, Jay Vaughan wrote:
> no, right, there are multiple MIDI API's on Linux and I think this is
> a good thing. I favour MidiShare, because its older, well-proven,
> cross-platform, and well and truly tested by its developers. I
> cannot say that for the MIDI par
Erik de Castro Lopo:
> >
> > I recently did a lot of benchmarking between libsamplerate and mus_src
> > in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
> > resampler where a lot faster than the fastest libsamplerate resampler.
>
> I think most people would agree that speed
At 7:36 -0400 13/6/05, Paul Davis wrote:
my point is that there is a big difference between saying there should
be a single API for MIDI on and a single implementation of
that API on . of course, the problem is that we don't have a
single API, even.
no, right, there are multiple MIDI API's on
Olivier Guilyardi wrote:
> Jackbeat is useful for my composition needs
OK, I've had a look at the webpage.
Firstly I see that its basically a drum machine. Drum hits are
relatively we behaved when linear sample rate converison is used.
Secondly, why don't you just do the sample rate conversion
On Mon, 2005-06-13 at 10:00 +0200, Jay Vaughan wrote:
> > > The idea that there should only be 'one' option for MIDI under Linux
> > > is ludicrous. Such thinking leads to cruft. I suppose there is only
> > > 'one' pthread lib too, eh? "Only One" libc?
> >
> >there is certainly only one pthre
On Monday 13 June 2005 12:11, Rui Nuno Capela wrote:
> QjackCtl 0.2.16 is finally out!
> As one can read from the changelog:
> - Long overdue transport buttons (rewind, backward and forward) finally
> landed onto the main control window, at last :).
Hurray!!! Looks great in the screenshot!
Arnold
Erik de Castro Lopo wrote:
Because the quality of linear converters is so poor, I have not
even attempted to optimise or even profile it.
I notice that it runs about 5 times faster than SRC_SINC_FASTEST
and on reflection, it should probably be 20 times faster. However,
I really didn't even expe
David Cournapeau wrote:
Olivier Guilyardi wrote:
Then, I coded a trivial sample rate conversion routine by myself :
- it sounds good, I can't hear any difference with the SRC_LINEAR
converter
I think the issue here is the application, and what you mean by good ?
If the usage is purely sampl
Olivier Guilyardi wrote:
> I believe libsamplerate, as a general purpose sample rate conversion library,
> should be able to run very fast if needed. After including your library into
> Jackbeat (http://www.xung.org/jackbeat) I was pretty sad to see 40% of my
> 700Mhz
> Duron load dedicated to
Olivier Guilyardi wrote:
Hi Erik,
Erik de Castro Lopo wrote:
Kjetil Svalastog Matheussen wrote:
I recently did a lot of benchmarking between libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src
sinc
resampler where a lot faster than the fastest li
QjackCtl 0.2.16 is finally out!
After laying around for a long time in the backyard (aka CVS:), the Qt
front-end to the one-of-a-kind JACK audio server daemon is finally made
public. Rejoyce!
As one can read from the changelog:
- ALSA sequencer client/port name changes are now properly detected
QjackCtl 0.2.16 is finally out!
After laying around for a long time in the backyard (aka CVS:), the Qt
front-end to the one-of-a-kind JACK audio server daemon is finally made
public. Rejoyce!
As one can read from the changelog:
- ALSA sequencer client/port name changes are now properly detected
Hi Erik,
Erik de Castro Lopo wrote:
Kjetil Svalastog Matheussen wrote:
I recently did a lot of benchmarking between libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
resampler where a lot faster than the fastest libsamplerate resampler.
I th
Alfons Adriaensen wrote:
> What do you mean by 'signal to noise ratio' of a resample algo ?
> I see no reason why it should produce noise, so it's probably not
> what the words suggest.
All sample rate conversion algorithms produce unwanted artifacts.
These artifacts are usually highly correlate
Alfons Adriaensen wrote:
On Mon, Jun 13, 2005 at 04:59:57PM +1000, Erik de Castro Lopo wrote:
With libsamplerate, I can state that the three sinc based converters
have the following characteristics:
SNRBandwidth
SRC_SINC_FASTEST 102.42 dB
On Mon, Jun 13, 2005 at 04:59:57PM +1000, Erik de Castro Lopo wrote:
> With libsamplerate, I can state that the three sinc based converters
> have the following characteristics:
>
> SNRBandwidth
> SRC_SINC_FASTEST 102.42 dB 80.23 %
> SR
Jay, if you're looking for cross-platform MIDI solutions there's
also PortMIDI which is being used as the primary MIDI system for
Csound5.
I'm actually not looking for cross-platform MIDI any more - MidiShare
does the job. What I am looking for is a way to use as very little
of ALSA as I pos
> The idea that there should only be 'one' option for MIDI under Linux
> is ludicrous. Such thinking leads to cruft. I suppose there is only
> 'one' pthread lib too, eh? "Only One" libc?
there is certainly only one pthread API, and only one libc API (although
there are newer versions of eac
Kjetil Svalastog Matheussen wrote:
>
> I recently did a lot of benchmarking between libsamplerate and mus_src
> in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
> resampler where a lot faster than the fastest libsamplerate resampler.
I think most people would agree that s
47 matches
Mail list logo
