Re: [Jack-Devel] not resampling

PrevNext  Index
DateSun, 06 Nov 2011 11:44:47 +0100
From richard lucassen <[hidden] at lucassen dot org>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToGabriel M. Beddingfield Re: [Jack-Devel] not resampling
On Sat, 05 Nov 2011 17:29:49 -0500
"Gabriel M. Beddingfield" <[hidden]> wrote:

> > I don't like resampling, especially when there is no need to. If I
> > need to restart or send a signal to jackd I don't win very much
> > using jack (is that right?), contrary to the use of a native 44100
> > mpd and a VLC (or any other program) that talks 48000 directly to
> > the soundcard.
> 
> For a "music consumer" type application, then indeed: you don't win
> very much using jack.  This includes flash players, media players,
> and media servers.  Instead of JACK you might consider using
> PulseAudio, ALSA plugins (e.g. dmix), or ROAR audio.

It's a standalone box without monitor. But I agree with you about using
jack or not. But jackd has the nice and easy possibility to connect
inputs to outputs. I have no idea if this is possible using ALSA
directly. The driver of my audiocard does not support yet the S/PDIF
input, but I finally like to be able to connect the S/PDIF input to an
output. And with Jack, this is no problem.

BTW and OT: does anyone know how to connect an input to an output using
ALSA?

> For a "music creator" type application, JACK is pretty friggin'
> awesome. This includes sequencers, synths, DJ, and multi-track
> recording applications..

I just want to play music, that's all :)

> > And this is the scenario here:
> >
> > - soundcard Terratec Sixfire USB
> >
> > - a bunch of flac files at 44100
> >
> > - A dreambox through S/PDIF (not implemented in the driver yet) or
> > through a webstream at 48000
> >
> > In the end I'd prefer to use the S/PDIF instead of the http stream.
> 
> This sounds more like a consumer-type application.  It's possible to
> use JACK in this type of use-case -- but you'll find yourself pissing
> in the wind a lot (and not able to get help on it).[1]  It's your
> call.

I fear you're right...

> [1] Examples:
>      * If application can't follow real time rules... it gets
>        disconnected and must be restarted.  This is unforgivable
>        for consumer use cases.  This is a bug in the application
>        in the creator use cases.

I found this on the net:

http://alsa.opensrc.org/Jack_and_Loopback_device_as_Alsa-to-Jack_bridge

AFAIUI this could be a nice solution to that issue. AFAIUI then.

>      * Client/server is pretty much a PITA in any use-case.
>        For creator use cases it's tolerated.  For consumer
>        use cases it results in streams of profanity.
>      * The overhead of a real-time set-up is a PITA, but totally
>        necc. in a creator use-case.  For the consumer use case,
>        getting a real-time setup is overkill and a great way
>        to lock up your system because of shoddy "consumer"
>        applications.

I have always used the -r option when jackd was started. But indeed, I
have to reconsider the use of jackd, although I like the simple setup
of it.

R.

-- 
____________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+
PrevNext  Index

1320576332.21661_0.ltw:2,a <20111106114447.b1e5e03429507f21f3545b57 at lucassen dot org>