- From: <bugzilla@jessica.w3.org>
- Date: Sun, 09 Sep 2012 22:12:27 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764 --- Comment #23 from Florian Bomers <w3c_bugz@bome.com> 2012-09-09 22:12:27 UTC --- (In reply to comment #22) > Maybe we need to specify the buffer handling in a way that implies that the > buffers need to be big enough to hold large SysEx message dumps like that. > After all, even 1MB at worst case isn't terribly much for one device given that > the benefit is that the developers generally don't need to worry about the > buffers getting overflown. > > Ideas? we should to distinguish 2 problems here: 1) buffer overflow on sending side. I propose to handle this with a "false" return value of the send() function. The buffer should not get too big (except for scheduled messages) to prevent accidental bursts. 2) buffer overflow on the receiving side. This is what I meant: many hardware devices are not capable to receive/process incoming MIDI data when it comes at full MIDI speed. For the sender, it is impossible to tell that the receiver cannot keep up. It's up to the specific application to throttle as needed for a specific hardware device, e.g. by a setting for the user. It can be implemented by having an API method for throttling, or by sending only small chunks of the big Sys Ex messages with delays in between. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Sunday, 9 September 2012 22:12:29 UTC