Re: USB fix (debian bug#100041)

Re: USB fix (debian bug#100041)

[Pedro Lopez-Cabanillas]

On Tuesday 11 March 2003 18:36, Clemens Ladisch wrote:
> Jordi Mallach wrote:
> > any comment on the last "stacatto" bug I reported after the big
> > report?
>
> I couldn't reproduce it on my machine (current CVS instead of 0.9.0beta8,
> 2.4.18 instead of 2.4.2, Roland Sound Canvas connected with USB instead of
> SB MIDI port).
>
> I have noticed that calling SNDCTL_SEQ_RESET (as well as close()ing the
> handle to /dev/music) sends "all notes off", "controller reset" and
> pitch-bend messages to all channels on all ports, but that should result
> in a delay of at most 40ms before the first note, and not in a timing
> problem at a later note.

After that messages, there is a 0xfe (Active Sensing) message (the rawmidi 
close() default policy). Running the test program with a Roland SC-88 
(connected with a MIDI cable to some  interface drived by ALSA) it shows this 
effect (first long note is clearly shortened). After the program reachs a 
delay of about 300ms the problem is solved, so i think that the Active 
Sensing can be guilty here. 

There is a description of ActiveSensing messages here:
http://www.midi.org/about-midi/table1.shtml
			Active Sensing.
                              Use of this message is optional.  When
                              initially sent, the receiver will expect
                              to receive another Active Sensing message
                              each 300ms (max), or it will be assume
                              that the connection has been terminated.
                              At termination, the receiver will turn off
                              all voices and return to normal (non-
                              active sensing) operation.

I have to say that with my other external synth (an old Roland JV-80) the test 
program runs fine (every note with the right length), but shows a "Midi 
Communication Error" in it's LCD display. The SC-88 shows another error 
message saying "Midi Off Line" every time a program close()s a rawmidi or OSS 
device.

I know that using ALSA rawmidi API, there is a function to prevent this, doing 
something like this:

		snd_rawmidi_t *handle_out;
		snd_rawmidi_params_t *params;
		[...]
		snd_rawmidi_params_malloc(&params);
		snd_rawmidi_params_current(handle_out, params);
		snd_rawmidi_params_set_no_active_sensing(handle_out, params, 1);
		snd_rawmidi_params(handle_out, params);
		snd_rawmidi_params_free(params);

But, how to do something like that for OSS programs? (without fixing the OSS  
program itself, of course)

Another way that i have tried to workaround the problem is redirect some 
source of Active Sensing events (using ALSA's aconnect, for instance) to the 
same output port (72:0) of the test program. This works, but is not a 
definitive solution at all.

BTW: my ALSA client 72 is a Midisport2x2. I can use it with a GPL firmware and 
also with the Midiman's propietary firmware, as you know.  Modifying the GPL 
firmware, i can block all the ActiveSensing events if i want. Isn't free 
software great? :-) 

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: USB fix (debian bug#100041)

[Clemens Ladisch]

Pedro Lopez-Cabanillas wrote:
> On Tuesday 11 March 2003 18:36, Clemens Ladisch wrote:
> > Jordi Mallach wrote:
> > > any comment on the last "stacatto" bug I reported after the big
> > > report?
> >
> > I couldn't reproduce it on my machine (current CVS instead of 0.9.0beta8,
> > 2.4.18 instead of 2.4.2, Roland Sound Canvas connected with USB instead of
> > SB MIDI port).
> >
> > I have noticed that calling SNDCTL_SEQ_RESET (as well as close()ing the
> > handle to /dev/music) sends "all notes off", "controller reset" and
> > pitch-bend messages to all channels on all ports, but that should result
> > in a delay of at most 40ms before the first note, and not in a timing
> > problem at a later note.
>
> After that messages, there is a 0xfe (Active Sensing) message (the rawmidi
> close() default policy). Running the test program with a Roland SC-88
> (connected with a MIDI cable to some  interface drived by ALSA) it shows this
> effect (first long note is clearly shortened). After the program reachs a
> delay of about 300ms the problem is solved, so i think that the Active
> Sensing can be guilty here.

Yes, that's it! My SC-8820 doesn't care for Active Sensing because the
connection status is handled by the USB protocol.

> I have to say that with my other external synth (an old Roland JV-80) the test
> program runs fine (every note with the right length), but shows a "Midi
> Communication Error" in it's LCD display. The SC-88 shows another error
> message saying "Midi Off Line" every time a program close()s a rawmidi or OSS
> device.

One could say "This behaviour is by design", but that's a Microsoft quote.
;-)

> I know that using ALSA rawmidi API, there is a function to prevent this, doing
> something like this:
> 		snd_rawmidi_params_set_no_active_sensing(handle_out, params, 1);
> But, how to do something like that for OSS programs? (without fixing the OSS
> program itself, of course)

Neither OSS nor ALSA sequencer ports can change parameters of the
underlying rawmidi port. Maybe there should be a module parameter for
this.


Regards,
Clemens




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: USB fix (debian bug#100041)

[Jaroslav Kysela]

On Wed, 12 Mar 2003, Clemens Ladisch wrote:

> > I know that using ALSA rawmidi API, there is a function to prevent this, doing
> > something like this:
> > 		snd_rawmidi_params_set_no_active_sensing(handle_out, params, 1);
> > But, how to do something like that for OSS programs? (without fixing the OSS
> > program itself, of course)
> 
> Neither OSS nor ALSA sequencer ports can change parameters of the
> underlying rawmidi port. Maybe there should be a module parameter for
> this.

Yes, if this behaviour causes troubles, we can specify the reset behaviour 
via a module parameter.

Perhaps, the best solution is to implement a control element which will
define the "reset" byte sequence when the rawmidi device is closed. Then
users might configure things themselves.

We can also rename snd_rawmidi_params_set_no_active_sensing() to 
snd_rawmidi_params_set_no_reset().

Opinions?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: USB fix (debian bug#100041)

[Clemens Ladisch]

Jaroslav Kysela wrote:
> On Wed, 12 Mar 2003, Clemens Ladisch wrote:
> > Neither OSS nor ALSA sequencer ports can change parameters of the
> > underlying rawmidi port. Maybe there should be a module parameter for
> > this.
>
> Yes, if this behaviour causes troubles, we can specify the reset behaviour
> via a module parameter.
>
> Perhaps, the best solution is to implement a control element which will
> define the "reset" byte sequence when the rawmidi device is closed. Then
> users might configure things themselves.

Yes. 0xFE, 0xFF, GM/GS/XG reset, or nothing may be usful in specific
situations.

> Opinions?

Seems to be a Good Thing(TM).


Regards,
Clemens




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: USB fix (debian bug#100041)

[Takashi Iwai]

At Wed, 12 Mar 2003 10:54:26 +0100 (CET),
Jaroslav wrote:
> 
> On Wed, 12 Mar 2003, Clemens Ladisch wrote:
> 
> > > I know that using ALSA rawmidi API, there is a function to prevent this, doing
> > > something like this:
> > > 		snd_rawmidi_params_set_no_active_sensing(handle_out, params, 1);
> > > But, how to do something like that for OSS programs? (without fixing the OSS
> > > program itself, of course)
> > 
> > Neither OSS nor ALSA sequencer ports can change parameters of the
> > underlying rawmidi port. Maybe there should be a module parameter for
> > this.
> 
> Yes, if this behaviour causes troubles, we can specify the reset behaviour 
> via a module parameter.
> 
> Perhaps, the best solution is to implement a control element which will
> define the "reset" byte sequence when the rawmidi device is closed. Then
> users might configure things themselves.

yes.  we can use IFACE_RAWMIDI for this control.
in which layer the implementation should come?  in the rawmidi
commonly?

> We can also rename snd_rawmidi_params_set_no_active_sensing() to 
> snd_rawmidi_params_set_no_reset().
 
sounds better.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en

Re: USB fix (debian bug#100041)

[Jaroslav Kysela]

On Wed, 12 Mar 2003, Takashi Iwai wrote:

> At Wed, 12 Mar 2003 10:54:26 +0100 (CET),
> Jaroslav wrote:
> > 
> > On Wed, 12 Mar 2003, Clemens Ladisch wrote:
> > 
> > > > I know that using ALSA rawmidi API, there is a function to prevent this, doing
> > > > something like this:
> > > > 		snd_rawmidi_params_set_no_active_sensing(handle_out, params, 1);
> > > > But, how to do something like that for OSS programs? (without fixing the OSS
> > > > program itself, of course)
> > > 
> > > Neither OSS nor ALSA sequencer ports can change parameters of the
> > > underlying rawmidi port. Maybe there should be a module parameter for
> > > this.
> > 
> > Yes, if this behaviour causes troubles, we can specify the reset behaviour 
> > via a module parameter.
> > 
> > Perhaps, the best solution is to implement a control element which will
> > define the "reset" byte sequence when the rawmidi device is closed. Then
> > users might configure things themselves.
> 
> yes.  we can use IFACE_RAWMIDI for this control.
> in which layer the implementation should come?  in the rawmidi
> commonly?

Yes, it belongs to the midlevel code - alsa-kernel/code/rawmidi.c.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en