From: Ryan Pavlik <rpav@nwlink.com>
To: Paul Davis <paul@linuxaudiosystems.com>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: MTP/AV / Sequencer MIDI problem... design issue?
Date: Sat, 11 Jan 2003 10:30:10 -0800 [thread overview]
Message-ID: <20030111103010.2d9588cd.rpav@nwlink.com> (raw)
In-Reply-To: <200301111355.h0BDtUX8028055@spider.tela.com>
(I'm checking out CVS again after Jaroslav Kysela's note, but I thought
I'd reply to this and clear up my statements.)
On Sat, 11 Jan 2003 08:55:10 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:
> its not a solution to the problem, but i think its important to note
> the behaviour of write(2) for FIFOs. <snip>
True, except the MTPAV driver writes byte-by-byte. ;)
<snip>
>
> >The userland solution, when writing raw midi, is to just put a mutex
> >on the device and never write an incomplete message.
> >
> >That is, of course, not an acceptable solution, and it also doesn't
>
> i'm afraid its an entirely acceptable solution, and its the same one
> required by many other non-audio, non-MIDI device types. if you have
> multiple threads writing to a disk-file, for example, and they
> interleave their calls to write(2), you will get mixed up data on
> disk.
Actually, I mean it's not an acceptable solution because (at least till
recent CVS I suppose) it's been the _only_ solution: things which (have)
used the sequencer interface to talk to the MTPAV on multiple outputs
simply didn't work. It can't be expected that everyone specially code
mtpav code, or that defeats the point of having ALSA.
But, of course, if you're writing to rawmidi, you'll probably have to
deal with this.
> >work when you're using the ALSA sequencer interface (at least from
> >the API calls I've seen).
>
> why not?
I have seen no ALSA API calls for "binding" devices together. You queue
up messages and they get sent... but putting a mutex around queue calls
doesn't do anything for you. (At least, I'm looking at this from what
the code said, and I very well could have been missing something.)
Anywayt, all of this should be moot if it's fixed now... off to compile.
;)
--
Ryan Pavlik <rpav@users.sf.net>
"DEPLOY THE ROCKET BOAT!"
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
next prev parent reply other threads:[~2003-01-11 18:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 19:37 MTP/AV / Sequencer MIDI problem... design issue? Ryan Pavlik
2003-01-11 13:55 ` Paul Davis
2003-01-11 18:30 ` Ryan Pavlik [this message]
2003-01-11 23:31 ` Paul Davis
2003-01-12 0:59 ` Ryan Pavlik
2003-01-12 1:50 ` Paul Davis
2003-01-12 4:37 ` Ryan Pavlik
2003-01-12 9:57 ` Jaroslav Kysela
2003-01-11 14:46 ` Jaroslav Kysela
2003-01-12 1:02 ` Ryan Pavlik
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=20030111103010.2d9588cd.rpav@nwlink.com \
--to=rpav@nwlink.com \
--cc=alsa-devel@lists.sourceforge.net \
--cc=paul@linuxaudiosystems.com \
/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.