From: Takashi Iwai <tiwai@suse.de>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Jaroslav Kysela <perex@suse.cz>,
Pedro Lopez-Cabanillas <plcl@telefonica.net>,
Michal Seta <mis@creazone.com>,
alsa-devel@lists.sourceforge.net
Subject: Re: MIDI+USB - one way?
Date: Mon, 05 Aug 2002 12:07:38 +0200 [thread overview]
Message-ID: <s5hn0s1ehzp.wl@alsa2.suse.de> (raw)
In-Reply-To: <3D4E3AB0.563AB976@ladisch.de>
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
next prev parent reply other threads:[~2002-08-05 10:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-02 5:15 MIDI+USB - one way? Michal Seta
2002-08-02 11:06 ` Clemens Ladisch
2002-08-02 13:35 ` Michal Seta
2002-08-02 13:07 ` Clemens Ladisch
2002-08-02 16:17 ` Pedro Lopez-Cabanillas
2002-08-02 17:08 ` Clemens Ladisch
2002-08-02 19:03 ` Patrick Shirkey
2002-08-02 19:34 ` Patrick Shirkey
2002-08-02 23:28 ` Pedro Lopez-Cabanillas
2002-08-03 0:21 ` Martin Langer
2002-08-04 12:07 ` Pedro Lopez-Cabanillas
2002-08-03 15:56 ` Patrick Shirkey
2002-08-04 18:50 ` Jaroslav Kysela
2002-08-05 8:43 ` Clemens Ladisch
2002-08-05 10:07 ` Takashi Iwai [this message]
2002-08-05 10:40 ` Clemens Ladisch
2002-08-05 12:24 ` Takashi Iwai
2002-08-05 12:54 ` Clemens Ladisch
2002-08-05 16:37 ` Jaroslav Kysela
2002-08-05 14:22 ` MIDI+USB - back on track Michal Seta
2002-08-07 13:38 ` Michal Seta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hn0s1ehzp.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@lists.sourceforge.net \
--cc=clemens@ladisch.de \
--cc=mis@creazone.com \
--cc=perex@suse.cz \
--cc=plcl@telefonica.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.