From: Clemens Ladisch <clemens@ladisch.de>
To: "Kalvas, Taneli" <taneli.v.m.kalvas@jyu.fi>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: RawMIDI behaviour with MidiFace 4x4
Date: Mon, 09 Mar 2015 22:47:32 +0100 [thread overview]
Message-ID: <54FE14F4.9070704@ladisch.de> (raw)
In-Reply-To: <6A72E9C91650BD49A6D9B305755BC04C42D8067A@mbs1.ad.jyu.fi>
Kalvas, Taneli wrote:
>>> I have tested the system by connecting the output port to an input
>>> port on the hardware and having another program output the received
>>> bytes on stdout. My observations:
>>> - As long as the buffer size is 276 bytes or less it gets sent ok
>>> - Larger buffer sizes cause corruption and roughly 300 bytes of received.
>>
>> This sounds as if the device has a buffer size of 256 bytes, but does
>> not actually check if the buffer is full, and always accepts more data.
>>
>> Does later data overwrite data that should have been sent earlier?
>
> By looking at the receiving end bytes it looks exactly like that has happened.
This pretty much proves that this is a bug in the device firmware.
You might try contacting Miditech ...
>>> Is there a way to connect two programs via a virtual RawMIDI port so
>>> that I could test without using the hardware?
>>
>> Load the snd-virmidi module, and connect two of its ports with aconnect.
>
> I did this and by using the virtual ports the behaviour is more
> reasonable, but still not as expected. Everything works ok as long as
> the message length is less than or equal to the buffer size (4096).
> With message sizes larger than that the writing end still claims it
> has sent everything, as it should do because the port is opened in
> blocking mode. On the reading end I can see that some data is missing
> and xruns are reported.
Oops, using snd-virmidi this way also goes through the sequencer, which
does not do blocking.
There is no other way to get a virtual RawMIDI port.
However, the driver was tested with lots of other devices, and huge
SysEx messages have this problem only with your device.
Regards,
Clemens
next prev parent reply other threads:[~2015-03-09 21:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-07 17:26 RawMIDI behaviour with MidiFace 4x4 Kalvas, Taneli
2015-03-09 8:38 ` Ricard Wanderlof
2015-03-09 8:47 ` Clemens Ladisch
2015-03-09 11:37 ` Kalvas, Taneli
2015-03-09 14:29 ` Ricard Wanderlof
2015-03-09 18:40 ` Clemens Ladisch
2015-03-09 8:43 ` Clemens Ladisch
2015-03-09 19:22 ` Kalvas, Taneli
2015-03-09 21:47 ` Clemens Ladisch [this message]
2015-03-10 7:32 ` Kalvas, Taneli
2015-03-10 8:02 ` Clemens Ladisch
2015-03-24 6:42 ` Kalvas, Taneli
2015-03-25 21:45 ` Clemens Ladisch
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=54FE14F4.9070704@ladisch.de \
--to=clemens@ladisch.de \
--cc=alsa-devel@alsa-project.org \
--cc=taneli.v.m.kalvas@jyu.fi \
/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.