Taybin wrote:
>This is what you want. This is from december. It just needs
>someone to implement it:
>"Thats why getting alsa-server to participate in JACK would be great:
>this would allow all regular ALSA apps to use JACK without its
>sample-sync features. The other way around doesn't wor
Great! of all people I think you understood what my point was with
this proposal.
I really have to work on improving my engish grammar.
> > 3-You may also want to put just any program that uses native
> > OSS/ALSA through this. Imagine running xmms and wanting to put the
> > sound thru a better
On Mon, 10 Jun 2002, Juan Linietsky wrote:
> Here's a problem I commonly find in existing audio apps or in
> programming audio apps: Audio routing.
Over a year ago (Sat May 05 2001) I wrote the following message:
http://www.eca.cx/lad/2001/May/0071.html
... pretty close isn't it? The next step
On Mon, Jun 10, 2002 at 09:30:36AM -0400, Paul Davis wrote:
(cut)
>Read the archives. We've been through this before. I'm not going
>through it again.
(cut)
ACK !
Every once in a while people bring up the same
questions people in this list
thought long and hard about and solved.
Before you st
>> Mostly because to do it correctly he argued that it has to be based
>> on a callback design and that is not part of the alsa-lib. Hence
>> JACK.
>>
>
>Sorry, obligatory question, what's wrong with blocking calls? :)
Read the archives. We've been through this before. I'm not going
through it a
>1-It's not a standard. ALSA/OSS are. If i want to write a driver, i
>will do for those.
JACK has nothing to do with device drivers. Its a layer that hides
even the existence of physical audio interfaces from
applications. Right now, there is a dynamically loaded client/clock
client that uses ALS
On Mon, 10 Jun 2002, Juan Linietsky wrote:
> 1-It's not a standard. ALSA/OSS are. If i want to write a driver, i
> will do for those.
In the open-source world, standards are defined by consensus. How do you
think gtk+ became a standard? People started using it. ALSA isn't in
POSIX either.
>
Juan Linietsky wrote:
> No, allow me to explain better why I think supporting JACK is
> pointless and why I wouldnt do it. I'll give you all the reasons I can
> think of.
[a bunch of pretty useless reasons]
> For these reasons, I will not support or use JACK until something like
> it becomes pa
> No, allow me to explain better why I think supporting JACK is
> pointless and why I wouldnt do it. I'll give you all the reasons I can
> think of.
>
> 1-It's not a standard. ALSA/OSS are. If i want to write a driver, i
> will do for those.
define standard.
> 3-Device sharing is pointless for
On Mon, 10 Jun 2002 09:52:10 +0100
Richard Bown <[EMAIL PROTECTED]> wrote:
> Juan Linietsky wrote:
>
> [developers choosing JACK over ALSA audio]
>
> > Not to be pessimistic, but I think such thing is not going to
> > happen. Also I find the whole idea redundant. If JACK is easier
> > and faste
Juan Linietsky wrote:
[developers choosing JACK over ALSA audio]
> Not to be pessimistic, but I think such thing is not going to happen.
> Also I find the whole idea redundant. If JACK is easier and faster to
> integrate then it should replace the ALSA api on that matter.
> Developers, and speci
On Mon, 10 Jun 2002 14:37:42 +0900
Patrick Shirkey <[EMAIL PROTECTED]> wrote:
> Juan Linietsky wrote:
>
> > Probably the easier and more natural approach to this is just
> > integrating JACK to ALSA in some way.
> >
> > What do you think?
> >
>
> Your idea has been discussed in length by Abra
12 matches
Mail list logo
