[Fwd: Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)]

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)]

Paul Davis
something Jay said below triggered a light bulb in my head. it might be
a mistake, but still ....

suppose that jackd had a --resample option that required backends to
provide an intermediate buffer between h/w and their ports. then we
decouple the process callback from the backend wait(), and run a
resampler from the return from wait(). it would be complicated, but it
would allow JACK to handle clients that want a different SR, and thus
open JACK up to desktop usage a little more.

comments? i am not sure i've even thought this out fully ...


-------- Forwarded Message --------
From: Jay Vaughan <[hidden email]>
To: [hidden email], The Linux Audio Developers' Mailing List
<[hidden email]>
Subject: Re: What Parts of Linux Audio Simply Work Great? (was Re:
[linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
Date: Thu, 16 Jun 2005 16:43:12 +0200
>true, but i take it you get the way CoreAudio is doing it: it means you
>can drive audio processing from a different interrupt source (e.g.
>system timer) because you have very accurate idea of the position of the
>h/w frame pointer. In CoreAudio, the "callback" is decoupled from any
>PCI, USB or ieee1394 interrupt. Tasty.

.. yes, very tasty.  the performance-enhancin "OS-provided"
ring-buffer/sample-rate convertor that this allows is also, of
course, tasty.




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great?

Jack O'Quin-2
Paul Davis <[hidden email]> writes:

> suppose that jackd had a --resample option that required backends to
> provide an intermediate buffer between h/w and their ports. then we
> decouple the process callback from the backend wait(), and run a
> resampler from the return from wait(). it would be complicated, but
> it would allow JACK to handle clients that want a different SR, and
> thus open JACK up to desktop usage a little more.
>
> comments? i am not sure i've even thought this out fully ...

Seems like a nice idea.  Could be useful for cards that only work
properly with one sample rate (generally 48KHz).

I recommend queuing this feature up for post-1.0.  If we don't make
many more big changes, I think JACK 1.0.0 could be released fairly
soon.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)]

deviant
In reply to this post by Paul Davis
yikes... the resampling could potentially have to happen between clients
aswell as at the backend. say for example you have a cd player client
asking for 44.1k, and that goes into a stereo enhancer client which is
operating at the soundcard sampling rate of 48k.
that is not impossible to deal with, but things could start getting
really hairy as soon as you add in more clients, each getting started up
with their own default sampling rate, and therefore resampling having to
be done after all of them. all of a sudden you are running out of cpu
and/or losing audio fidelity, and linux audio is not "just working",
even though that is what this feature is aimed at.
it's not necessarily a bad feature to provide, but some extremely
careful thought ought to go into it in order to prevent the situation i
outlined arising. and even if such funtionality is provided, client
authors should be strongly discouraged from using such functionality. it
is certainly a valid agrument that if a client needs a particular sample
rate, then that is a special case, and should be it's own responsibility
to implement.
ian


On Thu, 2005-06-16 at 11:04 -0400, Paul Davis wrote:

> something Jay said below triggered a light bulb in my head. it might be
> a mistake, but still ....
>
> suppose that jackd had a --resample option that required backends to
> provide an intermediate buffer between h/w and their ports. then we
> decouple the process callback from the backend wait(), and run a
> resampler from the return from wait(). it would be complicated, but it
> would allow JACK to handle clients that want a different SR, and thus
> open JACK up to desktop usage a little more.
>
> comments? i am not sure i've even thought this out fully ...
>
>
> -------- Forwarded Message --------
> From: Jay Vaughan <[hidden email]>
> To: [hidden email], The Linux Audio Developers' Mailing List
> <[hidden email]>
> Subject: Re: What Parts of Linux Audio Simply Work Great? (was Re:
> [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)
> Date: Thu, 16 Jun 2005 16:43:12 +0200
> >true, but i take it you get the way CoreAudio is doing it: it means you
> >can drive audio processing from a different interrupt source (e.g.
> >system timer) because you have very accurate idea of the position of the
> >h/w frame pointer. In CoreAudio, the "callback" is decoupled from any
> >PCI, USB or ieee1394 interrupt. Tasty.
>
> .. yes, very tasty.  the performance-enhancin "OS-provided"
> ring-buffer/sample-rate convertor that this allows is also, of
> course, tasty.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>
--
ian esten <[hidden email]>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great?

Jack O'Quin-2
ian esten <[hidden email]> writes:

> yikes... the resampling could potentially have to happen between clients
> aswell as at the backend. say for example you have a cd player client
> asking for 44.1k, and that goes into a stereo enhancer client which is
> operating at the soundcard sampling rate of 48k.

I think he meant only doing it at the backend.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great?

deviant
ah. fair enough, but what the user who reconnects the client, and all of
a sudden their audio is pitched up 1.5 semitones because the resampler
is no longer present?
i think that if this feature is to be included at all, it really has to
be dummy-proof.
ian

On Thu, 2005-06-16 at 23:07 -0500, Jack O'Quin wrote:
> ian esten <[hidden email]> writes:
>
> > yikes... the resampling could potentially have to happen between clients
> > aswell as at the backend. say for example you have a cd player client
> > asking for 44.1k, and that goes into a stereo enhancer client which is
> > operating at the soundcard sampling rate of 48k.
>
> I think he meant only doing it at the backend.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great?

Jack O'Quin-2
ian esten <[hidden email]> writes:

> ah. fair enough, but what the user who reconnects the client, and all of
> a sudden their audio is pitched up 1.5 semitones because the resampler
> is no longer present?
> i think that if this feature is to be included at all, it really has to
> be dummy-proof.

A good point.  

Paul said he had not thought it all out fully.  Neither have I.

My initial thought is that jack_get_sample_rate() should return the
"JACK" sample rate used by all the clients, not the "hardware" sample
rate used by the device.  The client can test that.  Starting jackd
with a different --resample value would then be no different than
starting with a different -r parameter.  The client would either make
its own adjustment, or the audio would come out at a higher pitch.
This situation already exists.  The only way I can see to make *that*
idiot-proof is in the client.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: What Parts of Linux Audio Simply Work Great? (was Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?)]

Glynn Clements
In reply to this post by Paul Davis

Paul Davis wrote:

> something Jay said below triggered a light bulb in my head. it might be
> a mistake, but still ....
>
> suppose that jackd had a --resample option that required backends to
> provide an intermediate buffer between h/w and their ports. then we
> decouple the process callback from the backend wait(), and run a
> resampler from the return from wait(). it would be complicated, but it
> would allow JACK to handle clients that want a different SR, and thus
> open JACK up to desktop usage a little more.
>
> comments? i am not sure i've even thought this out fully ...

Taking this a step further: would it be feasible for the backend to
compute the actual sample rate by timing, to allow binding multiple
soundcards together (e.g. 2 stereo cards = 4-channel I/O)?

If the backend resamples, it seems that it shouldn't matter if one
card is running at 47999Hz and the other 48001Hz, so long as you know
the actual sample rates.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel