Nabble - Jackit

Re: Using jack with no hw sound device

2009-11-27T02:59:06Z

Ng Oon-Ee wrote:

> On Fri, 2009-11-27 at 11:49 +0200, Nedko Arnaudov wrote:
>
>> "ingomega@..." <ingomega@...> writes:
>>
>>
>>> I'd like to make a sound server without
>>> plugging a sound card in it.
>>>
>>> Is it already possible using jack?
>>>
>> Yes, JACK has the 'dummy' driver.
>>
>
> Sorry for OT, but does any1 besides me find the answer funny? =p

On German this is called a "Kalauer".
http://www.dict.cc/deutsch-englisch/Kalauer.html
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: Using jack with no hw sound device

2009-11-27T02:43:53Z

On Fri, 2009-11-27 at 11:49 +0200, Nedko Arnaudov wrote:
> "ingomega@..." <ingomega@...> writes:
>
> > I'd like to make a sound server without
> > plugging a sound card in it.
> >
> > Is it already possible using jack?
>
> Yes, JACK has the 'dummy' driver.

Sorry for OT, but does any1 besides me find the answer funny? =p

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-27T02:37:31Z

On Fri, 2009-11-27 at 09:14 +0100, torbenh wrote:
> On Fri, Nov 27, 2009 at 07:32:39AM +0000, Peter Nelson wrote:
> > In a session environment the clients will not need to make any
> > connections. That is the session manager's job.
>
> well... i like ardours connection feature sometimes.
> ardour has so many ports, that its pretty hairy to setup connections via
> qjack, while its still pretty straigt forward.

I keep being unclear. I meant on session restore only.

However, perhaps I am doing it wrong then:

In sweeper I keep a reference to the jack_port_t around. When I want to
make or break a connection, the connection handler calls
jack_port_name() for both ports, therefore I don't have to keep an
up-to-date name around to change connections; the name is only used for
display. (This is of course different when it comes to saving connection
information.)

If you only keep the name, then you will of course need notifications to
even do connections.

--
Peter

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-27T01:49:45Z

yes, guitarix does not have the ambition to replace a generic connection manager. It only cares about its own ports :)

J.

--- On Fri, 11/27/09, torbenh <torbenh@...> wrote:

> From: torbenh <torbenh@...>
> Subject: Re: [Jack-Devel] jack_rename_client ( what notifications to send out ?)
> To: jack-devel@...
> Date: Friday, November 27, 2009, 4:37 AM
> On Fri, Nov 27, 2009 at 01:27:11AM
> -0800, James Warden wrote:
> > guitarix is also a client able to connect / disconnect
> its ports from any running jack clients via its own "client
> port map". When clients pop in or get out of the jack graph,
> the guitarix port map is automatically updated thanks to the
> existing port and client register callback mechanism. It
> would be a little annoying to break this functionality. I
> have nothing against qjackctl or patchage, but like for
> ardour, it is nice that the client you use often in your
> work provides its own connection UI.
> >
> > I am very much aware that this does not address any of
> the session management issues and is more of a narrow
> home-cooked solution that only addresses a very specific
> need in a very specific context (basically guitarix
> users).
>
> well... thats pretty much the reason why i am doing this
> inquiry.
> can i assume that guitarix will only connect its "own"
> ports ?
> because that can easiely be fixed by remembering the
> original name,
> and rewriting connect requests in jackd.
>
>
> --
> torben Hohn
> _______________________________________________
> 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

Re: Using jack with no hw sound device

2009-11-27T01:49:31Z

"ingomega@..." <ingomega@...> writes:

> I'd like to make a sound server without
> plugging a sound card in it.
>
> Is it already possible using jack?

Yes, JACK has the 'dummy' driver.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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

attachment0 (203 bytes) Download Attachment

Re: jack_rename_client ( what notifications to send out ?)

2009-11-27T01:37:38Z

On Fri, Nov 27, 2009 at 01:27:11AM -0800, James Warden wrote:
> guitarix is also a client able to connect / disconnect its ports from any running jack clients via its own "client port map". When clients pop in or get out of the jack graph, the guitarix port map is automatically updated thanks to the existing port and client register callback mechanism. It would be a little annoying to break this functionality. I have nothing against qjackctl or patchage, but like for ardour, it is nice that the client you use often in your work provides its own connection UI.
>
> I am very much aware that this does not address any of the session management issues and is more of a narrow home-cooked solution that only addresses a very specific need in a very specific context (basically guitarix users).

well... thats pretty much the reason why i am doing this inquiry.
can i assume that guitarix will only connect its "own" ports ?
because that can easiely be fixed by remembering the original name,
and rewriting connect requests in jackd.

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

Using jack with no hw sound device

2009-11-27T01:35:46Z

I'd like to make a sound server without
plugging a sound card in it.

Is it already possible using jack?

Voster,
G.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-27T01:27:11Z

guitarix is also a client able to connect / disconnect its ports from any running jack clients via its own "client port map". When clients pop in or get out of the jack graph, the guitarix port map is automatically updated thanks to the existing port and client register callback mechanism. It would be a little annoying to break this functionality. I have nothing against qjackctl or patchage, but like for ardour, it is nice that the client you use often in your work provides its own connection UI.

I am very much aware that this does not address any of the session management issues and is more of a narrow home-cooked solution that only addresses a very specific need in a very specific context (basically guitarix users).

J.

--- On Fri, 11/27/09, torbenh <torbenh@...> wrote:

> From: torbenh <torbenh@...>
> Subject: Re: [Jack-Devel] jack_rename_client ( what notifications to send out ?)
> To: jack-devel@...
> Date: Friday, November 27, 2009, 3:14 AM
> On Fri, Nov 27, 2009 at 07:32:39AM
> +0000, Peter Nelson wrote:
> > On Thu, 2009-11-26 at 18:47 -0500, David Robillard
> wrote:
> > > The only way you can say this could be not
> necessary is if you
> > > explicitly forbid ever referring to another jack
> client or port in any
> > > way whatsoever. This is maybe "possible"
> for some definition of
> > > "possible", but doesn't seem very realistic (or
> wise)...
> >
> > But apart from connection managers, how many clients
> do actually refer
> > to port names at all?
> >
> > In a session environment the clients will not need to
> make any
> > connections. That is the session manager's job.
>
> well... i like ardours connection feature sometimes.
> ardour has so many ports, that its pretty hairy to setup
> connections via
> qjack, while its still pretty straigt forward.
>
>
> >
> > --
> > Peter
> >
> > _______________________________________________
> > Jack-Devel mailing list
> > Jack-Devel@...
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
> --
> torben Hohn
> http://galan.sourceforge.net -- The graphical Audio
> language
> _______________________________________________
> 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

Re: how to avoid "midi events lost due to period crossing"

2009-11-27T00:27:59Z

Devin,

Just to throw a couple more things in...

Jitter -- whatever scheme is used should aim to minimise jitter; I'm not sure
holding back data until complete events are received is wise - that should not
be JACK's business. My gut feel is that JACK should have no knowledge of MIDI
message formats at all and just pass through data as it arrives.

This leads onto my second concern. Do (large) SysEx sequences currently break
JackFFADO? I'm assuming that's the case, given the code. It would be great if
any fix here could also allow for SysEx. (Remembering that there is an
indeterminate number of bytes between F0 and F7...)

-- Peter

Devin Anderson wrote:

> On Thu, Nov 26, 2009 at 5:37 AM, Peter L Jones <gmane@...> wrote:
>
>> When I get my new PC up and running, I'll be using an AudioFire4, so I want
>> FFADO working! :)...
>
> I wasn't going to discuss this until I was finished, but this seems
> like an appropriate time to discuss this.
>
> The reason I knew where this code was offhand is that I've been
> working on a fix to this problem, and other problems I have with the
> MIDI handling code. In particular:
>
> 1.) The FFADO MIDI code doesn't buffer all that much data between
> periods (4 bytes), and the amount isn't set up to be configurable.
> 2.) The FFADO MIDI code handles MIDI messages wrong in that the first
> byte is sent at the frame at which a MIDI message is scheduled to be
> sent, when I believe that, optimally, the _last_ MIDI byte should be
> sent when the message is scheduled to be sent.
> 3.) None of the hardware implementations handle realtime MIDI events.
> For JACK MIDI software, realtime MIDI events are handled just like any
> other event; essentially, every event is handled in realtime because
> the events are synced the way they are. However, when dealing with a
> physical MIDI port, you have to deal with a limited baud rate and what
> not. The solution I've been working on creates a class that sends
> realtime MIDI events as close as possible to the time that they're
> meant to be sent, and will interrupt other events to send them (i.e.
> sending two bytes of a 'note on' message, followed by the realtime
> MIDI event, followed by the last byte of a 'note on' message).
>
> When I'm done, I'll send in a patch.
>

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-27T00:14:36Z

On Fri, Nov 27, 2009 at 07:32:39AM +0000, Peter Nelson wrote:

> On Thu, 2009-11-26 at 18:47 -0500, David Robillard wrote:
> > The only way you can say this could be not necessary is if you
> > explicitly forbid ever referring to another jack client or port in any
> > way whatsoever. This is maybe "possible" for some definition of
> > "possible", but doesn't seem very realistic (or wise)...
>
> But apart from connection managers, how many clients do actually refer
> to port names at all?
>
> In a session environment the clients will not need to make any
> connections. That is the session manager's job.

well... i like ardours connection feature sometimes.
ardour has so many ports, that its pretty hairy to setup connections via
qjack, while its still pretty straigt forward.

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

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T23:32:39Z

On Thu, 2009-11-26 at 18:47 -0500, David Robillard wrote:
> The only way you can say this could be not necessary is if you
> explicitly forbid ever referring to another jack client or port in any
> way whatsoever. This is maybe "possible" for some definition of
> "possible", but doesn't seem very realistic (or wise)...

But apart from connection managers, how many clients do actually refer
to port names at all?

In a session environment the clients will not need to make any
connections. That is the session manager's job.

--
Peter

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T22:55:47Z

On Fri, Nov 27, 2009 at 08:24:10AM +0200, Nedko Arnaudov wrote:

good to have you participating again.

>
> I'd like to mention two things. First, process is allowed to have more
> than one jack client. Second, there is a way to get process id of
> non-internal jack clients. For jack2 it is in the mainline, both in the
> dbus api and in the jack.h api. For jack1, it is in the dbus patch only
> and IIRC not available through the jack.h api.

there are some clients, where associating the pid with the jack client,
is a bit cumbersome. oom is an example, its jack client is in another
process. (its still a child of the process the sessionmanager started)
, so it IS possible, to relate things back.

but as dave pointed out, if the client names are not restored, the
session is not restored correctly.

> As for rename stuff, I think unregister/register sequence should not
> be sent. If it is very important to not break (I doubt there will be
> regression actually) some apps instead of fixing them, clients could
> declare elevels of support. I.e. if rename callback is registered at
> client side, then client should not receive unregister/register
> notifications during rename. That said, I never seen port rename
> callback actually working. IIRC apps either rely that no external app
> renames [their] ports, or poll.

if an app registers for rename callback it wont receive
register/deregister callbacks. thats pretty obvious :) i dont think we
need to discuss about this case. although in the OP it was a question :)

the question is how fast fixed apps will show up on distros.
there will be a transition phase, and i basically just want to minimize
breakage during that phase.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T22:24:10Z

I'd like to mention two things. First, process is allowed to have more
than one jack client. Second, there is a way to get process id of
non-internal jack clients. For jack2 it is in the mainline, both in the
dbus api and in the jack.h api. For jack1, it is in the dbus patch only
and IIRC not available through the jack.h api.

As for rename stuff, I think unregister/register sequence should not
be sent. If it is very important to not break (I doubt there will be
regression actually) some apps instead of fixing them, clients could
declare elevels of support. I.e. if rename callback is registered at
client side, then client should not receive unregister/register
notifications during rename. That said, I never seen port rename
callback actually working. IIRC apps either rely that no external app
renames [their] ports, or poll.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

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

attachment0 (203 bytes) Download Attachment

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T20:28:12Z

On Thu, Nov 26, 2009 at 06:49:25PM -0500, David Robillard wrote:

> On Thu, 2009-11-26 at 23:20 +0100, fons@... wrote:
> > On Thu, Nov 26, 2009 at 10:45:52PM +0100, Stéphane Letz wrote:
> >
> > > Stupid question:why renaming clients... in the first place?
> >
> > Very good question. I've been trying all day to find a good
> > reason.
> >
> > IIRC this originated in the 'merging sessions' idea.
> >
> > When merging two sessions, there are three cases to
> > consider:
> [...]
> > 1. Both are already running. There can be no name conflicts.
> > 2. One is already running, the other is added.
> > The second one can be modified before it's launched.
>
> ...indeed. Modified, i.e. renaming
>
> The session manager obviously cannot "deep" modify the session since it
> does not understand everything stored on disk by every possible app.

i guess in fons world a well defined session protocoll would also
define, how clients save their state. so his idea of session management,
would be able to modify clients on disk.

however such a session protocoll doesnt meet our requirement of reducing
app patches to a bare minimum. so by our measure its poorly designed.

so in order to solve the problem of unique client names, we need to
rename clients which are live, and send out ClientRenameCallback to
clients interested in renaming clients.

continueing this, i have added:
int
jack_reserve_client_name( jack_client_t *client, const char *name, const char *uuid );

which associates a uuid with a client name. the client session interface
didnt change yet. so it still specifies its uuid on jack_client_open.
the server will assign the name associated with the uuid to that client
then.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T15:49:25Z

On Thu, 2009-11-26 at 23:20 +0100, fons@... wrote:

> On Thu, Nov 26, 2009 at 10:45:52PM +0100, Stéphane Letz wrote:
>
> > Stupid question:why renaming clients... in the first place?
>
> Very good question. I've been trying all day to find a good
> reason.
>
> IIRC this originated in the 'merging sessions' idea.
>
> When merging two sessions, there are three cases to
> consider:

[...]
> 1. Both are already running. There can be no name conflicts.
> 2. One is already running, the other is added.
> The second one can be modified before it's launched.

...indeed. Modified, i.e. renaming

The session manager obviously cannot "deep" modify the session since it
does not understand everything stored on disk by every possible app.

-dr

P.S. It's a useful feature anyway

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T15:47:12Z

On Thu, 2009-11-26 at 22:45 +0100, Stéphane Letz wrote:

> >>
> >> be re-linked or preserved).
> >
> > a) jack2 seems to have portrename callback.
> > b) i will add it.
> >
> > however i dont want break existing clients. because during transition
> > phase it might happen that some clients are broken.
> > i am specifically thinking about patchage here.
> > but patchage will be one of the first clients registering for renames, i
> > guess.
> >
> >
>
> Stupid question:why renaming clients... in the first place?

The name is the ID for a JACK client.

For session restoring to work, the names must be consistent, because
that is how clients refer to other clients. If you restore a session
containing some client that refers to "jack_metro", but the restored
jack_metro is not actually called "jack_metro", you havn't restored the
session. The session is broken.

The only way you can say this could be not necessary is if you
explicitly forbid ever referring to another jack client or port in any
way whatsoever. This is maybe "possible" for some definition of
"possible", but doesn't seem very realistic (or wise)...

-dr

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T14:20:43Z

On Thu, Nov 26, 2009 at 10:45:52PM +0100, Stéphane Letz wrote:

> Stupid question:why renaming clients... in the first place?

Very good question. I've been trying all day to find a good
reason.

IIRC this originated in the 'merging sessions' idea.

When merging two sessions, there are three cases to
consider:

1. Both are already running. There can be no name conflicts.
2. One is already running, the other is added.
The second one can be modified before it's launched.
The alternative is rely on Jack renaming apps automatically
in case there's a conflict. That would require a session
manager to accept than an app's name can be changed by Jack,
so the protocol must require that clients report the actual
name before the manager uses for its own purposes.
3. Both are just saved session files. As 2.

If there's any other reason to rename a client *while running*
it's probably just to cover up a problem in a poorly designed
session handling protocol. Which for me is no good reason to
break the Jack API by redefining the meaning of some callbacks.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T13:45:52Z

>>
>> be re-linked or preserved).
>
> a) jack2 seems to have portrename callback.
> b) i will add it.
>
> however i dont want break existing clients. because during transition
> phase it might happen that some clients are broken.
> i am specifically thinking about patchage here.
> but patchage will be one of the first clients registering for renames, i
> guess.
>
>

Stupid question:why renaming clients... in the first place?

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

Re: how to avoid "midi events lost due to period crossing"

2009-11-26T13:18:35Z

Devin,

Thanks, I'll hold off doing anything for now, then! :) Will you be
back-porting to Jack1?

-- Peter

Devin Anderson wrote:

..snip..
> When I'm done, I'll send in a patch.

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

Re: how to avoid "midi events lost due to period crossing"

2009-11-26T13:05:20Z

On Thu, Nov 26, 2009 at 5:37 AM, Peter L Jones <gmane@...> wrote:

> When I get my new PC up and running, I'll be using an AudioFire4, so I want
> FFADO working! :)...

I wasn't going to discuss this until I was finished, but this seems
like an appropriate time to discuss this.

The reason I knew where this code was offhand is that I've been
working on a fix to this problem, and other problems I have with the
MIDI handling code. In particular:

1.) The FFADO MIDI code doesn't buffer all that much data between
periods (4 bytes), and the amount isn't set up to be configurable.
2.) The FFADO MIDI code handles MIDI messages wrong in that the first
byte is sent at the frame at which a MIDI message is scheduled to be
sent, when I believe that, optimally, the _last_ MIDI byte should be
sent when the message is scheduled to be sent.
3.) None of the hardware implementations handle realtime MIDI events.
For JACK MIDI software, realtime MIDI events are handled just like any
other event; essentially, every event is handled in realtime because
the events are synced the way they are. However, when dealing with a
physical MIDI port, you have to deal with a limited baud rate and what
not. The solution I've been working on creates a class that sends
realtime MIDI events as close as possible to the time that they're
meant to be sent, and will interrupt other events to send them (i.e.
sending two bytes of a 'note on' message, followed by the realtime
MIDI event, followed by the last byte of a 'note on' message).

When I'm done, I'll send in a patch.

--
Devin Anderson
devin (at) charityfinders (dot) com

CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T11:52:52Z

On Thu, 2009-11-26 at 18:33 +0100, torbenh wrote:
> On Thu, Nov 26, 2009 at 10:43:40AM -0600, Gabriel M. Beddingfield wrote:
[...]
> > Moving the analogy back to JACK... JACK currently has
> > no way to communicate that port unregister/register pair
> > is actually a rename (and thus port connections should
> > be re-linked or preserved).
>
> a) jack2 seems to have portrename callback.

Client rename implies all the ports on it are renamed. This should be
explicitly in the docs, never send potentially hundreds of port renames
where one client rename will do, that can be REALLY inefficient.

> b) i will add it.
>
> however i dont want break existing clients. because during transition
> phase it might happen that some clients are broken.
> i am specifically thinking about patchage here.

This would affect any client at all that monitors such things, qjackctl,
ardour, etc, don't blame me! :)

> but patchage will be one of the first clients registering for renames, i
> guess.

Yep.

-dr

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

Re: how to avoid "midi events lost due to period crossing"

2009-11-26T11:44:21Z

On Thu, Nov 26, 2009 at 07:36:32PM +0000, Peter L Jones wrote:
> For the record, Noel's using Jack1, so the source is:
> http://trac.jackaudio.org/browser/trunk/jack/drivers/firewire/ffado_driver.c#L484
> ... but I don't see and radical difference. Noel isn't getting the "too much
> midi bytes cross period boundary" message at line 474 but gets a stream of the
> "events lost" messages with a decreasing count, which makes "some sense" as the
> count is "nevents-i-1" and i increments up to nevents each time around the
> loop. I'm suspicious that the "break" at line 486 actually needs to break out
> of the "i" loop rather than the "j" loop -- but I still don't like the idea of
> losing those events!

well.... 4 bytes of buffer are definitely too low.
the question is if it can be increased, without changing more code.
did you try increasing the value ?
what happens then ?

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

Re: how to avoid "midi events lost due to period crossing"

2009-11-26T11:36:32Z

For the record, Noel's using Jack1, so the source is:
http://trac.jackaudio.org/browser/trunk/jack/drivers/firewire/ffado_driver.c#L484
... but I don't see and radical difference. Noel isn't getting the "too much
midi bytes cross period boundary" message at line 474 but gets a stream of the
"events lost" messages with a decreasing count, which makes "some sense" as the
count is "nevents-i-1" and i increments up to nevents each time around the
loop. I'm suspicious that the "break" at line 486 actually needs to break out
of the "i" loop rather than the "j" loop -- but I still don't like the idea of
losing those events!

Devin Anderson wrote:

> On Thu, Nov 26, 2009 at 3:43 AM, torbenh <torbenh@...> wrote:
>> On Thu, Nov 26, 2009 at 11:32:11AM +0100, Noel Bush wrote:
>>> I am using jackd version 0.116.1 on Ubuntu 9.10, kernel 2.6.31-9-rt.
>>> I'm using the firewire driver to send MIDI via a2jmidid through a
>>> PreSonus Firebox to a MIDI keyboard. I have been trying to figure
>>> out how to avoid error messages saying "x midi events lost due to
>>> period crossing". These errors, of course, often cause all sorts of
>>> undesirable things to happen -- notes don't turn off, notes don't
>>> play, etc.
>>>
>>> Given what the message says about "period crossing", I've tried
>>> playing with the period and frames/buffer settings, but I can't
>>> really figure out what this is affecting. Any suggestions for how
>>> to tweak settings so I can avoid these errors altogether?
>> this looks like a bug in a2j ...
>> i dont think tweaking will help you.
>
> This is actually a limitation in the JACK FFADO drivers:
>
> http://trac.jackaudio.org/browser/jack2/trunk/jackmp/linux/firewire/JackFFADODriver.cpp
>
> Line 212 contains your error message.
>
> If I'm reading the code correctly, then only one MIDI byte is sent per
> 8 frames (given optimal scheduling), and the period crossing buffer is
> only 4 bytes in length; so, if two or more 'note on' messages are
> scheduled at the last frame of any period (not at all unlikely), then
> your first message will be buffered, and the rest will be lost.
>

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T10:31:03Z

On Thu, 2009-11-26 at 15:53 +0100, torbenh wrote:
> what are the notifications to send out, upon client rename ?
> as it also renames the ports, i guess we need to send:
>
> - portRegister, portUnregister
> - clientUnregister, clientRegister
> - clientRename (new callback)

If and only if a client doesn't support client_rename, whatever the
exact sequence that happens whenever a client (and its ports) goes away
should first fire. Then whatever the exact sequence that would happen
if the client and its ports were recreated should fire, then the
connections. Only one meaningful order really (connections depend on
ports depend on clients).

client_unregister implies the ports go away anyway, I forget if the port
events are actually sent in this case. Either way, just do whatever
normally happens.

> - graphReorder ?

This callback is meaningless and stupid, thus you can't really make an
sound argument for where it goes anyway :)

It's unlikely a client that understands the client/port/connect
callbacks even listens to it (since they provide the same information in
an actually useful form). Stick it anywhere, last probably makes the
most sense, since at that point the graph has actually changed and
looking at and rebuilding the state of absolutely everything (reason #2
this callback is stupid) will make sense at that point.

> shall a client which is listening for clientRename, get the
> register/unregister pairs ?

Absolutely not, dealing with these can be expensive, and it would either
result in doing the same thing twice or... some way of avoiding that
which I can't think of and might not even be possible. Firing them both
has kind of sketchy semantics anyway because of the name change.

Cheers,

-dr

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T10:00:06Z

On Thu, Nov 26, 2009 at 05:53:35PM +0000, Peter Nelson wrote:
> On Thu, 2009-11-26 at 17:31 +0100, torbenh wrote:
> > hmm.... in that case it would be correct to not send out notfications.
> > because we dont want patchbay to mess with it.
>
> Mmm, then perhaps it should be specified that they shouldn't do this, as
> it is indeed not a new port registration.
>
> On the other hand, what does qjackctl do when it detects a port has been
> renamed currently?

please not that i only want to do something sensible for legacy clients.
updated clients will listen for client_rename_callback and wont have
issues.
specifying something doesnt change legacy code.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T09:53:35Z

On Thu, 2009-11-26 at 17:31 +0100, torbenh wrote:
> hmm.... in that case it would be correct to not send out notfications.
> because we dont want patchbay to mess with it.

Mmm, then perhaps it should be specified that they shouldn't do this, as
it is indeed not a new port registration.

On the other hand, what does qjackctl do when it detects a port has been
renamed currently?

--
Peter

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T09:33:32Z

On Thu, Nov 26, 2009 at 10:43:40AM -0600, Gabriel M. Beddingfield wrote:

>
>
> On Thu, 26 Nov 2009, torbenh wrote:
>
> >On Thu, Nov 26, 2009 at 04:37:45PM +0100, fons@... wrote:
> >>
> >>If renames are allowed then a client that ignores
> >>this is broken.
> >>
> >>Unregister means the thing doesn't exist anymore.
> >>Then you rename an unexisting thing.
> >>Then you create a new one with the same name.
> >>
> >>Where's the logic ?
> >
> >where is the logic in git svn mapping a file rename to
> >Add and Delete in svn ?
> >
> >dunno. maybe git should just rename the stuff, and not tell upstream
> >subversion repo about it. bacause it doesnt support rename and is
> >therefor broken.
>
> While I understand your argument[1], does Fons actually use *any*
> VCS?? Much less, Git? :-P
>
> I tend to agree with Fons, you're renaming it... but it's the same
> port. So there shouldn't be an unregister/register. A port
> unregister means that all connections to the port are (or should be)
> severed... which is not what you want with a rename. However, AFAIK
> there is no notification system (i.e. a callback or mapping) that
> the name has changed.
>
> What you're suggesting is more of a workaround without changing the
> existing Jack API... which I also respect. :-)

wait. i WANT to change the API, i will a rename event.
BUT, i dont want to break existing clients, because that would be a
regression. this is an inquiry on how to achieve that.

if an updated client has a callback for rename set, its wont be
bothered. with these events.

> Moving the analogy back to JACK... JACK currently has
> no way to communicate that port unregister/register pair
> is actually a rename (and thus port connections should
> be re-linked or preserved).

a) jack2 seems to have portrename callback.
b) i will add it.

however i dont want break existing clients. because during transition
phase it might happen that some clients are broken.
i am specifically thinking about patchage here.
but patchage will be one of the first clients registering for renames, i
guess.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T08:43:40Z

On Thu, 26 Nov 2009, torbenh wrote:

> On Thu, Nov 26, 2009 at 04:37:45PM +0100, fons@... wrote:
>>
>> If renames are allowed then a client that ignores
>> this is broken.
>>
>> Unregister means the thing doesn't exist anymore.
>> Then you rename an unexisting thing.
>> Then you create a new one with the same name.
>>
>> Where's the logic ?
>
> where is the logic in git svn mapping a file rename to
> Add and Delete in svn ?
>
> dunno. maybe git should just rename the stuff, and not tell upstream
> subversion repo about it. bacause it doesnt support rename and is
> therefor broken.

While I understand your argument[1], does Fons actually use
*any* VCS?? Much less, Git? :-P

I tend to agree with Fons, you're renaming it... but it's
the same port. So there shouldn't be an
unregister/register. A port unregister means that all
connections to the port are (or should be) severed... which
is not what you want with a rename. However, AFAIK there is
no notification system (i.e. a callback or mapping) that the
name has changed.

What you're suggesting is more of a workaround without
changing the existing Jack API... which I also respect. :-)

-gabriel

[1] git-svn should try to do renames, but doesn't. Git is
able to detect renames and copies, and git-svn should
try to translate those. However, I'm sure that this
hasn't happened because the logic is complex... and
Git's copy/rename logic is much more promiscuous than
SVN's. Git will "detect" a copy even in some cases
where there wasn't actually a copy... but the content
between the two files is similar.

Moving the analogy back to JACK... JACK currently has
no way to communicate that port unregister/register pair
is actually a rename (and thus port connections should
be re-linked or preserved).
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T08:31:10Z

On Thu, Nov 26, 2009 at 04:16:09PM +0000, Peter Nelson wrote:

> On Thu, 2009-11-26 at 16:32 +0100, torbenh wrote:
> > could you please explain why ?
> > what should a client, who doesnt expect that client renames happen,
> > think in this case ?
> >
> > this is not about what *should* happen, but about what *needs* to happen
> > in order to have no client break.
> >
> > just saying there should *never* be any notifications without telling me
> > why qjack, patchage, and other things wont break, is not useful.
> >
> > maybe i am too careful, and there exist no clients which break if we
> > dont send out notifications.
> >
> >
> > qjackctl seems to be polling all ports and connections
> > anyways, it works fine with the current notationless rename.
> > we dont have so many clients which are interested in this kind of
> > notifications.
> > and port renames dont have notifications in jack1 anyways.
> >
> >
>
> I think there only needs to be a callback for port renaming, as if a
> client is renamed then its ports will also be renamed. As you say, this
> information can be polled anyway, so just a general "something was
> renamed" callback might be enough, rather than sending a callback for
> each port renamed.
>
> Most normal clients don't care about connections at all, let alone the
> port names, so it is only really a problem for connection managing
> programs.
>
> These managers will presumably reprocess their 'patchbay' functionality
> on the new port names.

hmm.... in that case it would be correct to not send out notfications.
because we dont want patchbay to mess with it.

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T08:16:09Z

On Thu, 2009-11-26 at 16:32 +0100, torbenh wrote:

> could you please explain why ?
> what should a client, who doesnt expect that client renames happen,
> think in this case ?
>
> this is not about what *should* happen, but about what *needs* to happen
> in order to have no client break.
>
> just saying there should *never* be any notifications without telling me
> why qjack, patchage, and other things wont break, is not useful.
>
> maybe i am too careful, and there exist no clients which break if we
> dont send out notifications.
>
>
> qjackctl seems to be polling all ports and connections
> anyways, it works fine with the current notationless rename.
> we dont have so many clients which are interested in this kind of
> notifications.
> and port renames dont have notifications in jack1 anyways.
>
>

I think there only needs to be a callback for port renaming, as if a
client is renamed then its ports will also be renamed. As you say, this
information can be polled anyway, so just a general "something was
renamed" callback might be enough, rather than sending a callback for
each port renamed.

Most normal clients don't care about connections at all, let alone the
port names, so it is only really a problem for connection managing
programs.

These managers will presumably reprocess their 'patchbay' functionality
on the new port names.

--
Peter

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T08:08:02Z

On Thu, Nov 26, 2009 at 04:37:45PM +0100, fons@... wrote:

> On Thu, Nov 26, 2009 at 04:32:55PM +0100, torbenh wrote:
>
> > this is not about what *should* happen, but about what *needs* to happen
> > in order to have no client break.
>
> If renames are allowed then a client that ignores
> this is broken.
>
> Unregister means the thing doesn't exist anymore.
> Then you rename an unexisting thing.
> Then you create a new one with the same name.
>
> Where's the logic ?

where is the logic in git svn mapping a file rename to
Add and Delete in svn ?

dunno. maybe git should just rename the stuff, and not tell upstream
subversion repo about it. bacause it doesnt support rename and is
therefor broken.

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T07:37:45Z

On Thu, Nov 26, 2009 at 04:32:55PM +0100, torbenh wrote:

> this is not about what *should* happen, but about what *needs* to happen
> in order to have no client break.

If renames are allowed then a client that ignores
this is broken.

Unregister means the thing doesn't exist anymore.
Then you rename an unexisting thing.
Then you create a new one with the same name.

Where's the logic ?

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

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T07:32:55Z

On Thu, Nov 26, 2009 at 04:13:43PM +0100, fons@... wrote:

> On Thu, Nov 26, 2009 at 03:53:57PM +0100, torbenh wrote:
>
> > what are the notifications to send out, upon client rename ?
> > as it also renames the ports, i guess we need to send:
> >
> > - portRegister, portUnregister
> > - clientUnregister, clientRegister
> > - clientRename (new callback)
> > - graphReorder ?
> >
> > shall a client which is listening for clientRename, get the
> > register/unregister pairs ?
>
> Rename (client or port) should *never* generate
> unregister/register. And since renaming should
> not have any impact on graph order, neither a
> graphreorder callback.

could you please explain why ?
what should a client, who doesnt expect that client renames happen,
think in this case ?

this is not about what *should* happen, but about what *needs* to happen
in order to have no client break.

just saying there should *never* be any notifications without telling me
why qjack, patchage, and other things wont break, is not useful.

maybe i am too careful, and there exist no clients which break if we
dont send out notifications.

qjackctl seems to be polling all ports and connections
anyways, it works fine with the current notationless rename.
we dont have so many clients which are interested in this kind of
notifications.
and port renames dont have notifications in jack1 anyways.

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

Re: jack_rename_client ( what notifications to send out ?)

2009-11-26T07:13:43Z

On Thu, Nov 26, 2009 at 03:53:57PM +0100, torbenh wrote:

> what are the notifications to send out, upon client rename ?
> as it also renames the ports, i guess we need to send:
>
> - portRegister, portUnregister
> - clientUnregister, clientRegister
> - clientRename (new callback)
> - graphReorder ?
>
> shall a client which is listening for clientRename, get the
> register/unregister pairs ?

Rename (client or port) should *never* generate
unregister/register. And since renaming should
not have any impact on graph order, neither a
graphreorder callback.

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

jack_rename_client ( what notifications to send out ?)

2009-11-26T06:53:57Z

what are the notifications to send out, upon client rename ?
as it also renames the ports, i guess we need to send:

- portRegister, portUnregister
- clientUnregister, clientRegister
- clientRename (new callback)
- graphReorder ?

shall a client which is listening for clientRename, get the
register/unregister pairs ?

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