|Re: [hatari-devel] MIDI support for Windows & OSX (with PortMidi)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] MIDI support for Windows & OSX (with PortMidi)
- From: Simon Iten <itensimon@xxxxxxxxx>
- Date: Tue, 3 Oct 2017 22:57:40 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Tl7Hzn9tlAr3QuzefIBAA0f6gP38kTzxBanc5DcouPw=; b=K+bIEFhpsO4PfObtwzvcTyFl+SaQm4GRWhjlOvL9xtVzN+ug6EzNdY6mllHWbM3ldT dA/X3siXymlcKAq7gYVWR4crV9AC6FGjszlAdNeSn/CrkW53EeQ9x4mem/x5w1fzuDtb eK7imkyCUswB/LnX4qscOa8QTZOCzFMqPzJnHLWSA9JuVZWFtGk9cQzbeNQ0T1Hl+z7i 5HJuGfi6JTYKaHNM2LOviyWcolMpzErmCedjJpmBC1zbZYkPLCXphC0qBlRe6KBYAfri wJ0lfh7tBVTgRHzPDggfCKwE7uU7AgzOTertwtMzQc4Swn6cewEUWmWTO1D/WyeAxvhi Jkag==
does or how does portmidi change the way midi is presented to a usb-midi converter?
or in other words, why does portmidi on osx behave differently (“better” in my case) then linux with the standard none portmidi method?
this is with the same atari software, same synth and same interface. driver issue on linux? (fastlane-usb motu, not fully class compliant)
> On 3 Oct 2017, at 22:10, Nicolas Pomarède <npomarede@xxxxxxxxxxxx> wrote:
> Le 03/10/2017 à 21:26, David Savinkoff a écrit :
>> ----- Eero Tamminen wrote:
>>> PS. Jari has also some questions about jitter he's seeing in MIDI output:
>> As a MIDI jitter testing experiment, try the following sound options:
>> --sound-buffer-size 10
>> --sound-sync true
>> These options affect emulation rate, and may improve the jitter.
> I'm not sure this would help ; for midi output, you'd want as realtime possible behaviour, which I think is better achieved when emulation speed is not audio driven but using usleep in the main loop.
> In that case if MFP expects a timer to last 1.39 sec for example under STF, then Hatari should take also exactly 1.39 sec.
> Plus, MIDI programs don't necessarily use the YM2149 chip, so you would have no audio data to sync with (except playing empty audio buffers).
> Put another way, I have more trust in usleep precision in that case than in syncing with an audio driver whose latency might vary depending on output sample rate or buffers size :)