Server control plug-ins proposal

[Nedko Arnaudov]

Fons Adriaensen <fons@...> writes:

>> If we have such massive rewrite to actually happen jackdbus interfaces
>> can be integrated in 'jack_control_daemon'.
>
> No, a jack system must not have a dbus dependency
> and be fully functional without dbus (provided there
> is _some_ control client).
>
> This is rather essential. The interface to the control
> daemon is provided by libjack, just as it is for audio
> clients. On top of that you build whatever you want, but
> it remains external.

I have not said that your slave boxes must have dbus dependency.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 4 juil. 09 à 15:24, Nedko Arnaudov a écrit :

> Fons Adriaensen <fons@...> writes:
>
>> On Thu, Jul 02, 2009 at 05:15:03PM -0400, Paul Davis wrote:
>>
>>> the existence of a/the control API does not solve the issue of
>>> pre-existing endpoints. got a suggestion there?
>>
>> Nothing new except for the two figures wich you will
>> find on <http://www.kokkinizita.net/linuxaudio/downloads>.
>>
>>
>> See jack1.pdf.
>> --------------
>>
>> This shows the general idea.
>>
>> 'jack_audio_server' is more or less what we know as jackd
>> today.
>>
>> 'jack_control_daemon' is the new thing.
>>
>> * It is started by the runlevel scripts as a service.
>>  If it isn't running there's no jack.
>
> This is not bad thing and I like this approach. jackdbus does  
> something
> similar but at desktop session level. Extending it to boot level is  
> good
> goal IMHO. If not changing it to boot level for all cases, JACK can at
> least (should) allow it.
>
>> * It waits for clients to register, which they do in the
>>  same way as jack apps register with the current jackd.
>>
>> * It provides the control API to registered clients.
>>  This includes discovery, configuration, starting
>>  and stopping of any number of 'jack_audio_server(s)'.
>>
>>  It provides optional callbacks allowing clients
>>  to be informed of
>>
>>    - jack_audio_server(s) starting, stopping,
>>      reporting errors, etc.
>>    - autolauch requests from applications.
>>    - possibly other events.
>
> If reinventing wheels is the only option because only posix stuff must
> be used, then this is then only way I guess.
>
>> * It is the *only* entity able/allowed to start or
>>  terminate a jack_audio_server.
>
> Good, this solves some of the problems I have with current classic
> infrastructure. But we need at least ardour and qjackctl to adopt this
> new system.
>
>> * It does *not* provide any persistence of configuration.
>
> Does it allow configuring the server (without persistency)? From your
> comments bellow, I think it does, right?
>
>> * There would in most cases be just one control client,
>>  but the API should allow for more to co-exist.
>>
>> The rest is fairly standard.
>
> I agree.
>
>> See jack2.pdf.
>> --------------
>>
>> This shows the control flow when an application wants
>> to launch a new jack_audio_server.
>>
>> 1. Libjack detects that the required jack_audio_server
>>   does not exist (or none exists at all), and diverts
>>   the call to jack_control_daemon.
>>
>> 2. Jack_control_daemon calls back to any of its clients
>>   that have requested to be informed of autolaunch.
>>
>> 3. Control clients either ignore the callback, or decide
>>   to configure a new jack_audio_server.
>>
>> 4. The control daemon starts the new jack_audio_server.
>>
>> If no clients are interested, the control daemon starts
>> a default server (based on ~/.jackdrc).
>
> If we have such massive rewrite to actually happen jackdbus interfaces
> can be integrated in 'jack_control_daemon'. Also such amount of work
> that you propose will solve in much more elegant way the autloaunching
> problem that some ppl have.
>
> Still I don't think mixing different infrastructure models at  
> runtime is
> good thing. It complicates the codebase thus requiring more  
> maintenance
> effort and I don't see how it helps because same end-user requirements
> can be achieved at compile time / packaging level. I.e. IMHO users  
> will
> either want OSC control (for dedicated boxes), dbus control (for linux
> desktop) or qjackctl/classic approach (for tradition
> beleivers). Allowing all of them mixed is call for trouble and will
> "cost" a lot to the development team.
>

As I understand Fons proposal allows control applications to be  
developed completely outside of JACK tree, by just using public  
headers and linking to the server library. Developing the  
infrastructure to allow that certainly is a new work for the  
development team but then having a DBus controler, or an OSC controler  
is a separated work.

Fons proposal does also require an IPC mechanism between the  
jack_audio_server and jack_control_daemon, and could possibly be  
simplified if a same process contains both parts (jack_control_daemon  
and one or several jack_audio_server..) This would mean that several  
JACK server would run in a same process, then a question that comes  
naturally: is running  several jack_audio_server a kind or corner case  
or not?

Anyway my suggestion is to release a 1.9.3 version in it's current  
state (regarding DBus code) with latest improvements and bug fixes  
quite soon, then I'll probably take some "vacation" from JACK project  
for a few time.

Stephane

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Nedko Arnaudov]

Stéphane Letz <letz@...> writes:

> Anyway my suggestion is to release a 1.9.3 version in it's current
> state (regarding DBus code) with latest improvements and bug fixes
> quite soon, then I'll probably take some "vacation" from JACK project
> for a few time.

Do you plan to merge the PA device reservation fixes against the trunk
version?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 7 juil. 09 à 14:35, Nedko Arnaudov a écrit :

> Stéphane Letz <letz@...> writes:
>
>> Anyway my suggestion is to release a 1.9.3 version in it's current
>> state (regarding DBus code) with latest improvements and bug fixes
>> quite soon, then I'll probably take some "vacation" from JACK project
>> for a few time.
>
> Do you plan to merge the PA device reservation fixes against the trunk
> version?
>

Makes sense yes, please do the merge and commit on SVN.

Thanks

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Guilherme Longo-2]

Is this necessary to use some special parameter to playback a raw audio
file?
I recorded a simple raw audio file using:

arecord -t raw file

and I am able to playback using:

aplay -t raw file.


But using a basic jack playback example, I get just a annoying noise. I
believe that its because JACK must need  a especial parameter  to deal
with  this type of media...  Am I  right??

Thank you!
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Tue, Jul 07, 2009 at 01:38:17PM -0300, Guilherme Longo wrote:

> Is this necessary to use some special parameter to playback a raw audio
> file?
> I recorded a simple raw audio file using:
>
> arecord -t raw file
>
> and I am able to playback using:
>
> aplay -t raw file.
>
>
> But using a basic jack playback example, I get just a annoying noise. I
> believe that its because JACK must need  a especial parameter  to deal with
>  this type of media...  Am I  right??

Jack is a system to interconnect audio apps to each other
and to a sound card. It does not play any files. You are
probably trying to use a jack application to play a file,
but without knowing which one it's impossible to answer
your question. So which player are you using ?

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Guilherme Longo-2]

This might be the issue, I didn't!

Just to make things more clear, what I have is a simple program that
sends the content of a voice recorded with no compression (raw) to my
sound card.

As I could understand, jack does it with no need of any special handling
regarding the format of the file. Is that ok?

Ill have a look at the sampling rate and Ill be back in case I can't
solve it!

Thank you!


ki.ber.kom.uni.st wrote:

> did you check samplerates in jack and of the audio file recorded?
>
> On Tue, Jul 7, 2009 at 6:38 PM, Guilherme
> Longo<grlongo.ireland@...> wrote:
>  
>> Is this necessary to use some special parameter to playback a raw audio
>> file?
>> I recorded a simple raw audio file using:
>>
>> arecord -t raw file
>>
>> and I am able to playback using:
>>
>> aplay -t raw file.
>>
>>
>> But using a basic jack playback example, I get just a annoying noise. I
>> believe that its because JACK must need  a especial parameter  to deal with
>>  this type of media...  Am I  right??
>>
>> Thank you!
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel@...
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>>    
>
>  

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jan Weil]

On Wed, Jul 08, 2009 at 01:37:43PM -0300, Guilherme Longo wrote:

> This might be the issue, I didn't!
>
> Just to make things more clear, what I have is a simple program that
> sends the content of a voice recorded with no compression (raw) to
> my sound card.
>
> As I could understand, jack does it with no need of any special
> handling regarding the format of the file. Is that ok?
>
> Ill have a look at the sampling rate and Ill be back in case I can't
> solve it!

It's probably not a sample rate but a sample format problem. Otherwise
it would only be played back at a faster or slower speed.

HTH

Jan
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Paul Davis]

On Wed, Jul 8, 2009 at 12:37 PM, Guilherme
Longo<grlongo.ireland@...> wrote:

> This might be the issue, I didn't!
>
> Just to make things more clear, what I have is a simple program that sends
> the content of a voice recorded with no compression (raw) to my sound card.
>
> As I could understand, jack does it with no need of any special handling
> regarding the format of the file. Is that ok?
>
> Ill have a look at the sampling rate and Ill be back in case I can't solve
> it!

jack requires mono, 32 bit floating point samples normalized to a +1
... -1 range for all audio. you didn't say where you got this
recording from, but its unlikely to be in this format unless it came
from JACK or some other "pro-audio-ish" application.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jonatan Liljedahl]

JACK doesn't care about any fileformats, it just sends samples between
apps and soundcard. What fileplayer example did you use? There is no way
for any program to guess the format of a RAW soundfile, one have to
supply it with the correct parameters (samplerate, samplesize, number of
channels). If the fileplayer example is the one I wrote for a long time
ago, it doesn't allow such parameters to be given but needs a soundfile
with a header with this info such as WAV or AIFF.

Guilherme Longo wrote:

> This might be the issue, I didn't!
>
> Just to make things more clear, what I have is a simple program that
> sends the content of a voice recorded with no compression (raw) to my
> sound card.
>
> As I could understand, jack does it with no need of any special handling
> regarding the format of the file. Is that ok?
>
> Ill have a look at the sampling rate and Ill be back in case I can't
> solve it!
>
> Thank you!
>
>
> ki.ber.kom.uni.st wrote:
>> did you check samplerates in jack and of the audio file recorded?
>>
>> On Tue, Jul 7, 2009 at 6:38 PM, Guilherme
>> Longo<grlongo.ireland@...> wrote:
>>  
>>> Is this necessary to use some special parameter to playback a raw audio
>>> file?
>>> I recorded a simple raw audio file using:
>>>
>>> arecord -t raw file
>>>
>>> and I am able to playback using:
>>>
>>> aplay -t raw file.
>>>
>>>
>>> But using a basic jack playback example, I get just a annoying noise. I
>>> believe that its because JACK must need  a especial parameter  to
>>> deal with
>>>  this type of media...  Am I  right??
>>>
>>> Thank you!
>>> _______________________________________________
>>> Jack-Devel mailing list
>>> Jack-Devel@...
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>
>>>    
>>
>>  
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

--
/Jonatan         [ http://kymatica.com ]
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org