usb-midi rc3 patch request

usb-midi rc3 patch request

[karsten wiese]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

hallo,

the attached patch exports two functions of usb-midi,
so other "device-owning" drivers can use usb-midi's
capabilities.
the patched usb-midi driver is used by the us428
driver through those exported functions. 
we can avoid having different alsa-devices for the
same physical device this way.
plus usb-midi can be used for non standard devices,
which need special initialisations through a special
driver first.
the patched usb-midi drivers should work in all other
cases exactly as before.

patch_usbmidi_rc3.tar.bz2 contains 
file "diffs" :  patch file
file "alsa-kernel/usb/usbmidi.h" : to be added header

best regards,
karsten


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de

[-- Attachment #2: patch_usbmidi_rc3.tar.bz2 --]
[-- Type: application/x-tbz, Size: 2471 bytes --]

Re: usb-midi rc3 patch request

[Takashi Iwai]

At Fri, 16 Aug 2002 12:34:50 +0200 (CEST),
karsten wiese wrote:
> 
> [1  <text/plain; iso-8859-1 (8bit)>]
> hallo,
> 
> the attached patch exports two functions of usb-midi,
> so other "device-owning" drivers can use usb-midi's
> capabilities.
> the patched usb-midi driver is used by the us428
> driver through those exported functions. 
> we can avoid having different alsa-devices for the
> same physical device this way.
> plus usb-midi can be used for non standard devices,
> which need special initialisations through a special
> driver first.
> the patched usb-midi drivers should work in all other
> cases exactly as before.

sorry, your patch looks still a bit hacky, perhaps because you wanted
to keep the usb-midi code as original as possible.

i think we need rather rewrite the top of usb device management (on
alsa).  there is also another problem in this regard, for example,
a device with both midi and audio is assigned to two different cards,
since midi and audio handles it individually.

let's discuss about it at first.

(BTW, could you check the legal condition of firmware on tascam
 device?  i'd like to put the stuffs but without this permission it's
 of course unacceptable...)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: usb-midi rc3 patch request

[karsten wiese]

 --- Takashi Iwai <tiwai@suse.de> wrote: > At Fri, 16
Aug 2002 12:34:50 +0200 (CEST),
> karsten wiese wrote:
> > 
> > hallo,
> >
> > the attached patch exports two functions of
usb-midi,
> > so other "device-owning" drivers can use
usb-midi's
> > capabilities.
> > the patched usb-midi driver is used by the us428
> > driver through those exported functions.
> > we can avoid having different alsa-devices for the
> > same physical device this way.
> > plus usb-midi can be used for non standard
devices,
> > which need special initialisations through a
special
> > driver first.
> > the patched usb-midi drivers should work in all
other
> > cases exactly as before.
>
> sorry, your patch looks still a bit hacky, perhaps
> because you wanted
> to keep the usb-midi code as original as possible.
>
> i think we need rather rewrite the top of usb device
> management (on
> alsa).  there is also another problem in this
> regard, for example,
> a device with both midi and audio is assigned to two
> different cards,
> since midi and audio handles it individually.

the patch adresses just that. here the output of
cat /proc/asound/devices
  0: [0- 0]: ctl
  8: [0- 0]: raw midi
 16: [0- 0]: digital audio playback
 24: [0- 0]: digital audio capture
  1:       : sequencer
 33:       : timer
 32: [1- 0]: ctl
 57: [1- 1]: digital audio capture
 48: [1- 0]: digital audio playback
 56: [1- 0]: digital audio capture
 40: [1- 0]: raw midi
 41: [1- 1]: raw midi

cat /proc/asound/cards
0 [card0          ]: ES1978 - ESS ES1978 (Maestro 2E)
                     ESS ES1978 (Maestro 2E) at
0x1400, irq 5
1 [card1          ]: USB US-428 - TASCAM US-428
                     TASCAM US-428 (1604:8001 if 0 at
001/003)

the us428 driver calls the snd-usb-midi like this:

 err = snd_usbmidi_card_create(  us428->dev,
     &us428->usbmidi,
        &us428->card,
     &us428->usbmidi_devnum
     );
interesting here is that us428->card has already been
initialized from the us428 driver before.
the patched snd_usbmidi_card_create() creates thus
er...  (hacky, cause the name doesnt fit anymore)
NO card on its own but uses the supplied one.
Would it be sufficient to add an extra function like
snd_usbmidi_card_attach() instead of overloading
snd_usbmidi_card_create()?

>
> let's discuss about it at first.
>
> (BTW, could you check the legal condition of
> firmware on tascam
>  device?  i'd like to put the stuffs but without
> this permission it's
>  of course unacceptable...)

what exactly do you need? I once tried to get an
answer from turtle beach,
which did not happen...
tascam will most likely not agree to release the
firmware under GPL in any form nor object- nor
source-code.
is it sufficient, if tascam just allows ALSA to use &
publish their firmware as it is now?
now it consists of char arrays in C header files
representing raw binary data sniffed from the win2k
USB.
tascam will likely want a comment in the header
stating that it is forbidden to disassemble,
that the code in that file is their property and may
only be used to compile the code & nothing else.
is there such a file header aside the GPL-world
already to be used as temlate?

AND does anybody know somebody @ TASCAM?

Karsten

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: usb-midi rc3 patch request

[Clemens Ladisch]

karsten wiese wrote:
> Takashi Iwai <tiwai@suse.de> wrote:
> > i think we need rather rewrite the top of usb device
> > management (on
> > alsa).  there is also another problem in this
> > regard, for example,
> > a device with both midi and audio is assigned to two
> > different cards,
> > since midi and audio handles it individually.
> 
> the patch adresses just that.
> ...
> Would it be sufficient to add an extra function like
> snd_usbmidi_card_attach() instead of overloading
> snd_usbmidi_card_create()?

This two-cards problem should be fixed for all USB devices,
not only for the Tascam. Then it wouldn't be necessary
to have special code for the MIDI part of the US428 at all.

I'm looking into this. usbaudio.c needs a function similar to
snd_usb_create_pcm(), but creating a sequencer device for
MIDI streaming interfaces. The sequencer device driver would
still be a separate module, but doesn't need to create
another card anymore.

> > (BTW, could you check the legal condition of
> > firmware on tascam
> >  device?  i'd like to put the stuffs but without
> > this permission it's
> >  of course unacceptable...)
> 
> what exactly do you need? I once tried to get an
> answer from turtle beach,
> which did not happen...
> tascam will most likely not agree to release the
> firmware under GPL in any form nor object- nor
> source-code.
> is it sufficient, if tascam just allows ALSA to use &
> publish their firmware as it is now?

I don't think they will allow their firmware to be
distributed with ALSA. (GPL requires to publish the
source.)

The Turtle Beach MultiSound driver uploads DSP code
from files installed with the Windows driver.
It may be possible to do the same for the US428.


Clemens


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: usb-midi rc3 patch request

[Takashi Iwai]

At Tue, 20 Aug 2002 10:41:52 +0200,
Clemens Ladisch wrote:
> 
> karsten wiese wrote:
> > Takashi Iwai <tiwai@suse.de> wrote:
> > > i think we need rather rewrite the top of usb device
> > > management (on
> > > alsa).  there is also another problem in this
> > > regard, for example,
> > > a device with both midi and audio is assigned to two
> > > different cards,
> > > since midi and audio handles it individually.
> > 
> > the patch adresses just that.
> > ...
> > Would it be sufficient to add an extra function like
> > snd_usbmidi_card_attach() instead of overloading
> > snd_usbmidi_card_create()?
> 
> This two-cards problem should be fixed for all USB devices,
> not only for the Tascam. Then it wouldn't be necessary
> to have special code for the MIDI part of the US428 at all.
> 
> I'm looking into this. usbaudio.c needs a function similar to
> snd_usb_create_pcm(), but creating a sequencer device for
> MIDI streaming interfaces. The sequencer device driver would
> still be a separate module, but doesn't need to create
> another card anymore.
 
that's also what i thought of.
we can make a common "base" module for managing the card (according to
the usb_device struct?).


> > > (BTW, could you check the legal condition of
> > > firmware on tascam
> > >  device?  i'd like to put the stuffs but without
> > > this permission it's
> > >  of course unacceptable...)
> > 
> > what exactly do you need? I once tried to get an
> > answer from turtle beach,
> > which did not happen...
> > tascam will most likely not agree to release the
> > firmware under GPL in any form nor object- nor
> > source-code.
> > is it sufficient, if tascam just allows ALSA to use &
> > publish their firmware as it is now?

if it's not allowed from the tascam, we cannot distribute the file nor
(binary) data in our package.  the workaround is to fetch the external
firmware file somehow as well as msnd driver does.


> I don't think they will allow their firmware to be
> distributed with ALSA. (GPL requires to publish the
> source.)
 
it's possible to distribute the binary firmware as it is.
in most cases, the firmware is regarded as "data", not a program.
(otherwise no hardware vendor will give it :)


> The Turtle Beach MultiSound driver uploads DSP code
> from files installed with the Windows driver.
> It may be possible to do the same for the US428.

yes, in the case of usb, it should be more easier than msnd driver,
since the access to usb device is possible from the userspace, too.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390