MIDI+USB - one way?

MIDI+USB - one way?

[Michal Seta]

Hi all,

I got a midisport2x2 interface.  I had it working with the usb-midi driver  but then I found out that alsa .rc3 had support for usb-midi.  So I got the CVS version and all compiled fine.  I had it working, too.  Now, for some strange reason, no matter what I try I am only able to get MIDI -out but can't get MIDI-in.  I havn't really tested with alsa compatible software (aseqview only) I need access to ramidi devices (well, for now).

Any ideas about such behaviour?
I'm on DebianPPC, 2.4.18, today's alsa's CVS.

thanks.
-- 
./MiS

Michal Seta		http://creazone.eworldmusic.com/doc/mis



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Michal Seta wrote:
> I got a midisport2x2 interface.  I had it working with the usb-midi
> driver  but then I found out that alsa .rc3 had support for usb-midi.
> So I got the CVS version and all compiled fine.  I had it working,
> too.  Now, for some strange reason, no matter what I try I am only
> able to get MIDI -out but can't get MIDI-in.  I havn't really tested
> with alsa compatible software (aseqview only) I need access to ramidi
> devices (well, for now).

I tested the snd-usb-midi driver with the ALSA rawmidi test programs
(rawmidi and midiloop in alsa-lib/test), and it worked.

I've already heard rumors that the OSS-compatible rawmidi input doesn't
work. Try to use /dev/snd/midiC?D? instead.

It seems I'll have to do some further testing over the weekend ...


HTH
Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Michal Seta]

On Fri, 02 Aug 2002 13:06:32 +0200
Clemens Ladisch <clemens@ladisch.de> wrote:
> 
> I tested the snd-usb-midi driver with the ALSA rawmidi test programs
> (rawmidi and midiloop in alsa-lib/test), and it worked.

It didn't work for me.

when called with -i option it is silent (and I am unable to ctrl-c it to exit - I have to kill the proces).  With the -o option it sends note on/note off properly.  And yes, I used the -v option as well.

> 
> I've already heard rumors that the OSS-compatible rawmidi input doesn't
> work. Try to use /dev/snd/midiC?D? instead.

I used that, too.  And at all times I get MIDI output working fine but no input.  The funny thing is that it _did_ work and then it stopped working just like that...


Thanks anyways...

-- 
./MiS

Michal Seta		http://creazone.eworldmusic.com/doc/mis




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Michal Seta wrote:
> The funny thing is that it _did_ work and then it stopped working just like that...

Is there something suspicious in /var/log/messages?


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Pedro Lopez-Cabanillas]

El Vie 02 Ago 2002 15:35, Michal Seta escribió:
> On Fri, 02 Aug 2002 13:06:32 +0200
> Clemens Ladisch <clemens@ladisch.de> wrote:
> > I tested the snd-usb-midi driver with the ALSA rawmidi test programs
> > (rawmidi and midiloop in alsa-lib/test), and it worked.
>
> It didn't work for me.
>
> when called with -i option it is silent (and I am unable to ctrl-c it to
> exit - I have to kill the proces).  With the -o option it sends note
> on/note off properly.  And yes, I used the -v option as well.

I have a Midiman Midisport 2x2 too, and is working with snd-usb-midi and Lars 
Doelle's ezusbmidi firmware. I have tested it just now, with current cvs's  
alsa-lib/test/rawmidi program and it works for me.

And yes, ctrl-c does not work well with this program. It only works after some 
events received from the MIDI device. If there is no MIDI input for some 
reason (cable disconnected, wrong parameters) you have to kill it.

$ ./rawmidi -v -i hw:2,0
Using:
Input: device hw:2,0
Output: NONE
Read midi in
Press ctrl-c to stop
read fe
read fe
read fe
read fe
read fe
read fe
read fe
Closing

>
> > I've already heard rumors that the OSS-compatible rawmidi input doesn't
> > work. Try to use /dev/snd/midiC?D? instead.

It also works for me with OSS emulation:

$ ./rawmidi -v -I /dev/midi02
Using:
Input: /dev/midi02
Output: NONE
Read midi in
Press ctrl-c to stop
read fe
read fe
read fe
read fe
read fe
read fe
read fe
Closing

But something as simple as:
$ cat /dev/midi02 | od -x
Doesn't work. Nothing received. ?!

>
> I used that, too.  And at all times I get MIDI output working fine but no
> input.  The funny thing is that it _did_ work and then it stopped working
> just like that...

A broken MIDI cable, perhaps? Also, keep watch over hotplug and the usb-oss 
modules/usb-audio modules. Sorry, I can't think of any more suggestions.

Regards,
Pedro



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Pedro Lopez-Cabanillas wrote:
> It also works for me with OSS emulation:
> 
> $ ./rawmidi -v -I /dev/midi02
> Using:
> Input: /dev/midi02
> Output: NONE
> Read midi in
> Press ctrl-c to stop
> read fe
> read fe
> read fe
> read fe
> read fe
> read fe
> read fe
> Closing
> 
> But something as simple as:
> $ cat /dev/midi02 | od -x
> Doesn't work. Nothing received. ?!

rawmidi.c uses the ALSA library functions to access the rawmidi device.
Internally, alsa-lib should use the same read() call as cat, but there
seems to be a difference somewhere, maybe in the initialization.
I'm looking into it.


HTH
Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Patrick Shirkey]

Hey.

I am just about ready to release the new alsa docs to the general public .

Can you guys tell me what the differences are in installing the card 
compared to the standard template. thx.

http://www.alsa-project.org/alsa-doc/

(just open up a couple of pages and you should see what I mean).




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Patrick Shirkey]

Patrick Shirkey wrote:

> Can you guys tell me what the differences are in installing the card 
> compared to the standard template. thx.
> 

Sorry I meant:

Can you guys tell me what the differences are in installing a midi  card 
compared to the standard template. thx.





-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Pedro Lopez-Cabanillas]

El Vie 02 Ago 2002 21:03, Patrick Shirkey escribió:
> Hey.
>
> I am just about ready to release the new alsa docs to the general public .
>
> Can you guys tell me what the differences are in installing the card
> compared to the standard template. thx.
>
> http://www.alsa-project.org/alsa-doc/
>
> (just open up a couple of pages and you should see what I mean).

First, I need to say that perhaps I'm not the best source of information, as 
I've been here, or as an ALSA user for a short time, and because my poor 
english. So please, if I'm wrong on something let me know and correct my 
mistakes.

I suppose that you want to know about the MIDI only devices, and specifically  
the Midiman MidisportNxN. 

MIDI only devices (without digital audio) are not new. The first I had, a long 
time ago, was a Roland MPU-401. And as the newer ones, it had only MIDI 
ports, not digital audio, nor mixer. As a general rule, a template for these 
devices (kmod / modules.conf section) can be something like this:

        # ALSA portion
        alias char-major-116 snd
        alias snd-card-0 snd-usb-midi
        # module options should go here

        # OSS/Free portion
        alias char-major-14 soundcore
        alias sound-slot-0 snd-card-0

        # card #1
        alias sound-service-0-1 snd-seq-oss
        alias sound-service-0-8 snd-seq-oss

Also, there is not need to mention alsamixer nor snd-pcm-oss, snd-mixer-oss  
or some other audio only program. Volume and other sound parameters are  
usually embedded inside the MIDI stream. 

About the .asoundrc file, I think that it has nothing to do with these 
devices, but perhaps I'm wrong and it has some useful function for MIDI.

There are a few devices supposed to work with snd-usb-midi driver that have 
also an Audio function, though, as the Roland/Edirol SC-8820 and SC-8850. In 
this case, the audio portion of that devices need the snd-usb-audio driver. 
You can put both buttons in the driver column for these devices as they need 
two drivers simultaneously.

As a side note, the name "card" is not very appropiate in the USB land. They 
are all external devices, (MIDI adaptors, keyboards, drum controllers and 
surely soon guitars, wind controllers, etc.), connected by the USB cable to 
the computer or USB hub. Another surprising issue is that in the ALSA 
soundcard matrix there is no one Roland/Edirol device. The snd-usb-driver 
works with a couple of MIDI  adapters and synthesizers from Roland, as you 
can see at Clemens page: 
http://www.informatik.uni-halle.de/~ladischc/usbmidid.html

We have also a report from Martin Langer, that his MK-249C USB MIDI keyboard 
from Evolution Electronics Ltd. works with the snd-usb-midi driver.
http://www.evolution.co.uk/products/keyboards_01.htm

Finally, some points about the Midiman MidisportNxN. For the "chipset" column, 
you can mention here "ezusb" (or better, "Cypress AN2131", see:  
http://www.cypress.com/products/datasheet.cfm?partnum=AN2131SC for technical 
reference manuals and developement kits). This chipset is widely used in USB 
peripherals, not only MIDI ones, and it is related to Intel 8051 chip.

As an example, I know that Midiman has some USB MIDI keyboards using ezusb, 
that perhaps can work with snd-usb-midi.
USB Keystations: http://www.midiman.net/products/midiman/keystations.php
Steinberg has also a ezusb compatible USB MIDI Adaptor:
http://www.harmony-central.com/Newp/1999/USB-2-MIDI-Interface.html

As some other devices built around the ezusb circuits, the MidisportNxN 
devices need a firmware program to be loaded from the host thru the USB 
cable. Midiman did not released his firmware for Linux, but we are using a 
nice GPL one, by Lars Doelle, that can be obtained from: 
http://member.nifty.ne.jp/Breeze/softwares/unix/bin/usbmidi-20020324.tar.gz

Inside the tarball, there is a testing/Midisport directory with sources, 
documents and two files: ezusbmidi1x1.ihx and ezusbmidi2x2.ihx
These are the precompiled firmware programs for Midisport1x1 and 2x2. For 4x4 
and 8x8, you can put a "coming soon" advice :),  as they had not yet been 
released.

A good place to put the ezusbmidiNxN.ihx files is the 
/usr/share/usb/ezusbmidi/ directory, according to the Linux Standard Base. 
But you can put it elsewhere, fixing the appropiate scripts.
To load the firmware into the device, the Linux-hotplug utility 'fxload' can 
be used. The best way to do so is letting hotplug to take care of that, but 
first, you need to install hotplug, and edit some files (as root).

# pico /etc/hotplug/usb.usermap
ezusbmidi    0x0003 0x0763 0x1010 0 0 0 0 0 0 0 0 0
ezusbmidi    0x0003 0x0763 0x1001 0 0 0 0 0 0 0 0 0
ezusbmidi    0x0003 0x0763 0x1020 0 0 0 0 0 0 0 0 0
ezusbmidi    0x0003 0x0763 0x1030 0 0 0 0 0 0 0 0 0

# pico /etc/hotplug/usb/ezusbmidi
#!/bin/sh
FIRMWARE=
FLAGS=
LOADER=/sbin/fxload
# pre-renumeration device IDs
case $PRODUCT in
# Midisport 1x1
763/1010/*)
    FIRMWARE=/usr/share/usb/ezusbmidi/ezusbmidi1x1.ihx
    ;;
# Midisport 2x2
763/1001/*)
    FIRMWARE=/usr/share/usb/ezusbmidi/ezusbmidi2x2.ihx
    ;;
esac
# quit unless we were called to download some firmware
if [ "$FIRMWARE" = "" ]; then
    if [ -x /usr/bin/logger ]; then
        /usr/bin/logger -t $0 "there is not a firmware for $PRODUCT ??"
    fi
    exit 1
fi
# missing firmware?
if [ ! -r $FIRMWARE ]; then
    if [ -x /usr/bin/logger ]; then
        /usr/bin/logger -t $0 "missing $FIRMWARE for $PRODUCT ??"
    fi
    exit 1
fi
# missing loader?
if [ ! -x $LOADER ]; then
    if [ -x /usr/bin/logger ]; then
        /usr/bin/logger -t $0 "missing $LOADER ??"
    fi
    exit 1
fi
if [ -x /usr/bin/logger ]; then
    /usr/bin/logger -t $0 "load $FIRMWARE for $PRODUCT to $DEVICE"
fi
$LOADER $FLAGS -I $FIRMWARE


Regards,
Pedro



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Martin Langer]

On Sat, Aug 03, 2002 at 01:28:52AM +0200, Pedro Lopez-Cabanillas wrote:
> 
> As a side note, the name "card" is not very appropiate in the USB land. They 
> are all external devices, (MIDI adaptors, keyboards, drum controllers and 
> surely soon guitars, wind controllers, etc.), connected by the USB cable to 
> the computer or USB hub. Another surprising issue is that in the ALSA 
> soundcard matrix there is no one Roland/Edirol device. The snd-usb-driver 
> works with a couple of MIDI  adapters and synthesizers from Roland, as you 
> can see at Clemens page: 
> http://www.informatik.uni-halle.de/~ladischc/usbmidid.html
> 
> We have also a report from Martin Langer, that his MK-249C USB MIDI keyboard 
> >from Evolution Electronics Ltd. works with the snd-usb-midi driver.
> http://www.evolution.co.uk/products/keyboards_01.htm
> 

Let's say, the time of a general midi-interface is over since USB is coming
more and more to the midi world! 

Do we need an usb-midi device matrix? Up to now we have not much devices, but 
the list is growing and alsa midi documents are rare. Perhaps we should 
change this situation and start with a small midi-matrix or a general
usb-matrix. 

It's just an idea. 

martin


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Pedro Lopez-Cabanillas]

El Sáb 03 Ago 2002 02:21, Martin Langer escribió:
> Do we need an usb-midi device matrix? Up to now we have not much devices,
> but the list is growing and alsa midi documents are rare. Perhaps we should
> change this situation and start with a small midi-matrix or a general
> usb-matrix.

In fact, we have already a general usb device matrix, see:
http://www.qbik.ch/usb/devices/showdevcat.php?id=7

Regards,
Pedro



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Patrick Shirkey]

Pedro Lopez-Cabanillas wrote:
>
> First, I need to say that perhaps I'm not the best source of information, as 
> I've been here, or as an ALSA user for a short time, and because my poor 
> english. So please, if I'm wrong on something let me know and correct my 
> mistakes.
> 

Thanks Pedro and Martin. I have made some additions for the usb-midi docs.




-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.boosthardware.com/LAU/guide/
========================================



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Jaroslav Kysela]

On Fri, 2 Aug 2002, Clemens Ladisch wrote:

> Pedro Lopez-Cabanillas wrote:
> > It also works for me with OSS emulation:
> > 
> > $ ./rawmidi -v -I /dev/midi02
> > Using:
> > Input: /dev/midi02
> > Output: NONE
> > Read midi in
> > Press ctrl-c to stop
> > read fe
> > read fe
> > read fe
> > read fe
> > read fe
> > read fe
> > read fe
> > Closing
> > 
> > But something as simple as:
> > $ cat /dev/midi02 | od -x
> > Doesn't work. Nothing received. ?!
> 
> rawmidi.c uses the ALSA library functions to access the rawmidi device.
> Internally, alsa-lib should use the same read() call as cat, but there
> seems to be a difference somewhere, maybe in the initialization.
> I'm looking into it.

Note that the cat utility (od probably too) uses big input buffer. If you 
want to capture byte-stream, use the dd utility with the block size of 1 
byte.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Jaroslav Kysela wrote:
> On Fri, 2 Aug 2002, Clemens Ladisch wrote:
> > rawmidi.c uses the ALSA library functions to access the rawmidi device.
> > Internally, alsa-lib should use the same read() call as cat, but there
> > seems to be a difference somewhere, maybe in the initialization.
> 
> Note that the cat utility (od probably too) uses big input buffer. If you
> want to capture byte-stream, use the dd utility with the block size of 1
> byte.

No, the size of the input buffer must not prevent read() from returning
data which is available immediately.  IOW: if some data is available,
read() mustn't block.  ALSA's current read() implementation is wrong in
this regard.

This isn't only incompatible to OSS, but also to any other implementation
of read() in Linux (or any other Unix-like OS, not to mention POSIX or
SUS).


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Takashi Iwai]

At Mon, 05 Aug 2002 10:43:28 +0200,
Clemens Ladisch wrote:
> 
> Jaroslav Kysela wrote:
> > On Fri, 2 Aug 2002, Clemens Ladisch wrote:
> > > rawmidi.c uses the ALSA library functions to access the rawmidi device.
> > > Internally, alsa-lib should use the same read() call as cat, but there
> > > seems to be a difference somewhere, maybe in the initialization.
> > 
> > Note that the cat utility (od probably too) uses big input buffer. If you
> > want to capture byte-stream, use the dd utility with the block size of 1
> > byte.
> 
> No, the size of the input buffer must not prevent read() from returning
> data which is available immediately.  IOW: if some data is available,
> read() mustn't block.  ALSA's current read() implementation is wrong in
> this regard.
> 
> This isn't only incompatible to OSS, but also to any other implementation
> of read() in Linux (or any other Unix-like OS, not to mention POSIX or
> SUS).

how about pcm?  it must be blocked unless O_NONBLOCK is specified.

this issue is regardless how the other unix-like os are, but we need
to refer to _only_ posix here.  eventually, linux is not a unix clone
:)

imo, in the case of midi, this blocking behavior is nothting but
annoying.  hence i agree to change this behavior, as long as the
change doesn't break the posix standard.
(and i believe that no applications suffer by this change.)


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > No, the size of the input buffer must not prevent read() from returning
> > data which is available immediately.  IOW: if some data is available,
> > read() mustn't block.  ALSA's current read() implementation is wrong in
> > this regard.
> >
> > This isn't only incompatible to OSS, but also to any other implementation
> > of read() in Linux (or any other Unix-like OS, not to mention POSIX or
> > SUS).
> 
> how about pcm?  it must be blocked unless O_NONBLOCK is specified.
> 
> this issue is regardless how the other unix-like os are, but we need
> to refer to _only_ posix here.  eventually, linux is not a unix clone
> :)
> 
> imo, in the case of midi, this blocking behavior is nothting but
> annoying.  hence i agree to change this behavior, as long as the
> change doesn't break the posix standard.

O_NONBLOCK specifies the behaviour only in the case when no data is
available at the time read() is called. When some data is available
later, read() must not block (again), regardless of this flag.

To quote one of the standards (I think IEEE 1003.1 is POSIX)
<http://www.opengroup.org/onlinepubs/007904975/functions/read.html>:
| When attempting to read a file (other than a pipe or FIFO) that
| supports non-blocking reads and has no data currently available:
|
| If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].
|
| If O_NONBLOCK is clear, read() shall block the calling thread until
| some data becomes available.
|
| The use of the O_NONBLOCK flag has no effect if there is some data
| available.
| [...]
| Upon successful completion, where nbyte is greater than 0, read()
| (...) shall return the number of bytes read. This number shall never
| be greater than nbyte. The value returned may be less than nbyte if
| (...) the file is a (...) special file and has fewer than nbyte bytes
| immediately available for reading. For example, a read() from a file
| associated with a terminal may return one typed line of data.

> (and i believe that no applications suffer by this change.)

Yes, because applications expect the OSS behaviour.

I didn't really look at the OSS PCM read() implementation, but the
sequencer read() already implements the correct POSIX behaviour.


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Takashi Iwai]

At Mon, 05 Aug 2002 12:40:19 +0200,
Clemens Ladisch wrote:
> 
> To quote one of the standards (I think IEEE 1003.1 is POSIX)
> <http://www.opengroup.org/onlinepubs/007904975/functions/read.html>:
> | When attempting to read a file (other than a pipe or FIFO) that
> | supports non-blocking reads and has no data currently available:
> |
> | If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].
> |
> | If O_NONBLOCK is clear, read() shall block the calling thread until
> | some data becomes available.
> |
> | The use of the O_NONBLOCK flag has no effect if there is some data
> | available.
> | [...]
> | Upon successful completion, where nbyte is greater than 0, read()
> | (...) shall return the number of bytes read. This number shall never
> | be greater than nbyte. The value returned may be less than nbyte if
> | (...) the file is a (...) special file and has fewer than nbyte bytes
> | immediately available for reading. For example, a read() from a file
> | associated with a terminal may return one typed line of data.

ok, it's clearly mentioned here.
then we should fix this behavior.


> 
> > (and i believe that no applications suffer by this change.)
> 
> Yes, because applications expect the OSS behaviour.
> 
> I didn't really look at the OSS PCM read() implementation, but the
> sequencer read() already implements the correct POSIX behaviour.

i don't think that the oss pcm interface ever suffices the definition
of posix above.  but we cannot change it since most of applications
assume that the read aligned in a block size.

in the case of alsa, this low-level behavior can be changed, because
the difference can be absorbed inside the alsa-lib.  but i see no good
reason to change this now.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Clemens Ladisch]

Takashi Iwai wrote:
> Clemens Ladisch wrote:
> > > (and i believe that no applications suffer by this change.)
> >
> > Yes, because applications expect the OSS behaviour.
> >
> > I didn't really look at the OSS PCM read() implementation, but the
> > sequencer read() already implements the correct POSIX behaviour.
> 
> i don't think that the oss pcm interface ever suffices the definition
> of posix above.  but we cannot change it since most of applications
> assume that the read aligned in a block size.

Sorry, I didn't mention that I do _not_ intend to change the PCM code.
It's fine as it is.

> in the case of alsa, this low-level behavior can be changed, because
> the difference can be absorbed inside the alsa-lib.

Both the OSS and native ALSA code finally use snd_pcm_lib_read() as far
as I see, so it could not be changed independently. (but I didn't look
deeply into this)

And there's already sleep_min or something like that, so we are beyond
POSIX anyway.

> but i see no good reason to change this now.

Neither do I.


Clemens


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - one way?

[Jaroslav Kysela]

On Mon, 5 Aug 2002, Takashi Iwai wrote:

> At Mon, 05 Aug 2002 12:40:19 +0200,
> Clemens Ladisch wrote:
> > 
> > To quote one of the standards (I think IEEE 1003.1 is POSIX)
> > <http://www.opengroup.org/onlinepubs/007904975/functions/read.html>:
> > | When attempting to read a file (other than a pipe or FIFO) that
> > | supports non-blocking reads and has no data currently available:
> > |
> > | If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN].
> > |
> > | If O_NONBLOCK is clear, read() shall block the calling thread until
> > | some data becomes available.
> > |
> > | The use of the O_NONBLOCK flag has no effect if there is some data
> > | available.
> > | [...]
> > | Upon successful completion, where nbyte is greater than 0, read()
> > | (...) shall return the number of bytes read. This number shall never
> > | be greater than nbyte. The value returned may be less than nbyte if
> > | (...) the file is a (...) special file and has fewer than nbyte bytes
> > | immediately available for reading. For example, a read() from a file
> > | associated with a terminal may return one typed line of data.
> 
> ok, it's clearly mentioned here.
> then we should fix this behavior.

Fixed.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - back on track

[Michal Seta]

Hi all,

So, my MIDI-in is working now.
I don't know why, I don't know why it didn't work before and I'm not sure it will work the next time I need to reboot or reconnect my MIDI interface.

Thanks everyone for suggestions but here's what was happening:

My MIDI cables were OK.
I don't use any other usb-audio devices.
When I was sending MIDI from the synth to the computer the light on the interface was blinking so I assume it was getting into the interface but for some reason not into the computer.  

I was away for the weekend so I turned off the computer.  This morning, when I booted up, loaded the firmaware, loaded the snd-usb-midi stuff it still didn't work. Then, I noticed, my synth (Roland GR-50) was displaying an error message (MIDI buffer overflow) but I haven't seen any lights on the interface.  I disconnected the MIDI cables, turned the synth off, reconnected MIDI cables, turned the unit on and voilà.  Everything works.  Now, I'm not sure if I really want to try to reproduce it.  But I think it's unrelated to the drivers (unless some initialization causes some kind of MIDI jam).

rawmidi works as expected
dd bs=1 </dev/snd/midiCxDx works, too.
cat does not (as reported earlier)

thanks.
-- 
./MiS

Michal Seta		http://creazone.eworldmusic.com/doc/mis




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: MIDI+USB - back on track

[Michal Seta]

Hi all,

Sorry to annoy you with replies to myself but I thought I'd leave a record of my troubles and a fix.

On Mon, 5 Aug 2002 09:22:58 -0500
Michal Seta <mis@creazone.com> wrote:

> I was away for the weekend so I turned off the computer.  This morning, when I booted up, loaded the firmaware, loaded the snd-usb-midi stuff it still didn't work. Then, I noticed, my synth (Roland GR-50) was displaying an error message (MIDI buffer overflow) but I haven't seen any lights on the interface.  I disconnected the MIDI cables, turned the synth off, reconnected MIDI cables, turned the unit on and voilà.  Everything works.  Now, I'm not sure if I really want to try to reproduce it.

The adventurous part of me said: 'Yeah! go for it!'
so I did.

It is consistently behaving like this.  If I upload the firmware to the mididsport while my synth is on it will not work properly.  If the synth is off (and turn it on after the upload) then everything works as expected.

I have only a Roland GR-50 unit so it could be _only_ this model behaving like that.  Maybe it's just me.  Thanks everyone.

-- 
./MiS

Michal Seta		http://creazone.eworldmusic.com/doc/mis



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf