Buffer size issue in preferences/Audio System...

[MythicMike]

Hydrogen version * : 1.1.0 Operating system + version : W10 latest verion Audio driver + version : PortAudio / Windows Direct Sound

---

Hello,

Instrument sound is horrible (i.e. like a bad reverb) when the value of the size of the buffer is set lower than 861.

It should be possible to set it lower in order to diminish as much as possible de time lag between the action on eDrum pads (I use a TDV6 Roland eDrum and module to pilot the Hydrogen Software).

A value of 861 works well, but a short time lag is always present and induce a strange feeling when drumming (I do not know the value of time lag left, may be few tens of milliseconds).

Values greater than 861 work well also, but greater the value, greater the time lag.

The configuration on which I use Hydrogen 32 bits is a PC Windows 10/64 bits (latest version) with 4 Go Ram, Core i3, 2Ghz.

Best regards

Michel

---

• H2 version : see 'Info - About', or in case you build Hydrogen from source use 'git rev-parse HEAD' ** if you are reporting a bug, please describe how the bug can be reproduced

[cme]

There's more to latency on Portaudio than buffer size -- it's dependent on the requested latency (which currently is always chosen to be the safest, see #1352), the host api and the sound device.

What sound hardware is being used?

There are multiple different things that could be happening to create the audio effect you describe. Could you capture a wav from your system demonstrating the issue (and without it) ? Or if not, is the tempo correct? (that's a useful diagnostic)

I'm very surprised there are issues with such a large buffer size so I'm keen to get to the bottom of it.

Is the size of buffer you're using the result of trial and error to see where the behaviour starts?

Thanks!

[MythicMike]

Thank you very much for your prompt answer.

I will retrieve the information you need to investigate, however I tried Hydrogen on another PC Windows 10/64 bits 8go RAM Core I5, I can reproduce the issue, but the min buffer size in not the same and it is around 500. I succeed to use Hydrogen with a buffer size of 512 samples.

I have other machines on which I can try and give you some results.

By the way, is there something specific to use Jack in the audio system. I tried but I was not successful as Hydrogen trends to crash when I select it. Is there somewhere a tutorial or some explanations how to use it?

Many thanks and best regards.

Michel

[theGreatWhiteShark]

I succeed to use Hydrogen with a buffer size of 512 samples.

Does this mean for a buffer size of 512 the problem disappears and there is no problem with the sound anymore? If so, does the picture change when you set it to 511 or 513?

[cme]

By the way, is there something specific to use Jack in the audio system. I tried but I was not successful as Hydrogen trends to crash when I select it. Is there somewhere a tutorial or some explanations how to use it?

JACK needs to be installed separately, and will need to be the most recent version (I have had success installing it via Chocolatey) since JACK has very tight dependencies between its server and library.

(If you have JACK already installed and it's a different version, you should be able to get Hydrogen to work with it by replacing the libjack.dll / libjack64.dll in Hydrogen with the libjack.dll / libjack64.dll from your existing JACK installation) but I haven't been able to try this)

If you can get JACK to work with Windows that should be a lot better, latency-wise, than PortAudio.

On the topic of PortAudio, two asides:

• you might get better results by changing the 'Host API' setting to one of the other host APIs
• having a fixed-size buffer at all might be introducing extra latency, so I intend to change things to use dynamic buffer sizing instead, and use only a target latency setting.

[MythicMike]

Hello, thank you for your answers and comments ...

For the first point:

I succeed to use Hydrogen with a buffer size of 512 samples.

Does this mean for a buffer size of 512 the problem disappears and there is no problem with the sound anymore? If so, does the picture change when you set it to 511 or 513?

In this case, the issue appear if the buffer size is lower than 512 sample. For other values greater than 512, there is no sound problem. The configuration on which this behavior appears is a Dell Lattitute, i5 6300 U, 8 Go RAM, 2.4/2.5 Ghz, Windows 64 bits. Sound hardware seems to be basic Intel and Realtek controller.

Regarding JACK and optimization of latency:

JACK needs to be installed separately, and will need to be the most recent version (I have had success installing it via Chocolatey) since JACK has very tight dependencies between its server and library.

I think I already have the last version installed, so I will try your proposal to replace the Hydrogen libjack.dll by the JACK one.

Regarding host API selection:

On the topic of PortAudio, two asides:

* you might get better results by changing the 'Host API' setting to one of the other host APIs

Already done, I tried the 4 APIs available (i.e. MME, Windows Direct Sound, Windows Wasapi and Windows WD-MKS) and selected the more reactive one which is, on mys side, the Windows Direct Sound one.

I will continue to perform some tests on my side and will let you know the results.

However, many thanks again for your help, comments and proposals.

Best regards

Michel

[MythicMike]

Good evening,

Just tried Hydrogen on another PC. In instance it is a mini laptop PC HP with the following characteristics: Intel Atom CPU N570 (1.66 Ghz/1.67 Ghz), 2 GO Ram, Windows 32 bits (I believe it is a specific version, but Microsoft official, as it is supported by a very small hardware configuration). I think the sound card is a basic one managed by MS High Definition Audio.

Hydrogen works properly (I was really and positively suprized to be able to use it on a so small configuration) and regarding the buffer size the lowest limit before obtaining altered sound is 420, so different from the other results obtained on the other machines. I was not able to use JACK on this machine (not possible to establish the link between JACK server and Hydrogen, even if I updated the libjack.dll as preconized above.). So I used the Portaudio/Windows Direct Sound audio configuration. The result is not so bad at all, even if I have a really short latency (as I feel it, I do not have any mean to measure the time latency between pad triggering and sound play starting) when drumming.

In addition, using Portaudio / Windows Direct Sound , I obtain really good results using the i5 based Dell PC configuration, and when I compare with the Jack audio configuration, it is really hard to see if there is a difference or not as the drumming feeling is good in both case, even if I believe that there is an additional small latency compared the original modules of my edrum kit (Roland TDV6 and XM 110S).

Hopping it gives some clues or rooms to improve this really nice piece of software which Hydrogen is.

Best regards

Michel

[cme]

Hi @MythicMike,

Would you mind giving this development build a try?

This contains changes (#1388) which should reduce the achievable latency with PortAudio. It removes the fixed-buffer-size constraint, which should allow PortAudio to reduce latency with some APIs, and also allows the user to set a target latency (in terms of number of frames). The actual latency (or at least PortAudio's estimation of it) can be seen in the Debug -> Audio Engine info window.

(Note that previously with PortAudio, setting the buffer size to something small doesn't reduce latency, only reduces the minimum latency PortAudio can achieve if it's asked to -- before this change, Hydrogen would always ask for the driver's "safe" latency, which is often horrible).

[cme]

It seems that PortAudio sets a fairly pessimistic hard floor for most Windows Host APIs. There's a way to work around it with an environment variable, but using the WDM-KS HostAPI seems to allow a lower latency (at least on the Windows 11 VM I have) and the difference it makes is just brilliant.

[MythicMike]

Hello @cme ,

Thank you very much for your feedback, update and work around.

Regarding the WDM-KS HostAPI, is it already implemented in Hydrogen and if it is the case, what is the way as simple user to specifically select the diver that implements this API?

Again, many thanks for your help.

Best regards

Michel

[cme]

WDM-KS is a HostAPI setting, so can be selected with the "Host API" drop-down which shows "Windows DirectSound" in your screenshot. That may not actually be the best HostAPI as I found DirectSound actually got a better latency on a real Windows machine. It may differ between machines based on hardware and drivers, and again you'll have to experiment to find the best settings.

[MythicMike]

Thanks again for your answer.

At this time Windows DirectSound is already set in the parameters and following some tests, I agree, it seems to present the smallest latency. This was tested on the latest Hydrogen 32 bits versions.

I am going to install the development version you indicated to see the difference. By the way do you have also a 32 bits version of this development version?

Brs

Michel

[MythicMike]

Good evening,

Some tests done with the development version 64 bits on the following configuration:

• Laptop Acer A717-71G Intel(R), Core(TM) i5-7300HQ CPU @ 2.50GHz 12 Go RAM, Windows 10 Family, version 21H1

• Smallest targeted latency before sound degradation : 1413 frames with the following parameters:

• Debug info:

• Caution: the application crashes when I try to validate the midi entry selection using portmidi so not possible to test it with a midi keyboard or an eDrum. Please, note that it works without problem with the official stable latest Hydrogen version (v1.1.0 32 bits version):

• In term of UX and reactivity, sound trigger seems very prompt to react (human feeling using mouse to trig instruments), no delay felt between the mouse button click and the instrument sound generation.

======================================================= 2nd test sequence done with the following parameters:

• No sound degradation even with a Latency target of 0.
• However the debug info is really more pessimistic than the previous test result with a value of estimated latency at 7952 frames:
• Regarding midi interface, same result than previous test, Hydrogen crashes when validating the selection of midi interface.
• In term of UX, obviously delay is felt, not possible to use it in live drum session.

====================================================== 3rd test sequence:

• Same results than the 2nd test sequence
• Midi interface : application crash.
• UX : same delay felt than for 2nd test

======================================================= 4th test sequence:

• Same results than test sequences 2 and 3.

======================================================= So at the end, the best parameters on my PC configuration is

• 

Hoping it helps.

Brs

Michel

[cme]

Hi @MythicMike, there's a 32-bit version of the bulid here: https://ci.appveyor.com/api/buildjobs/fo3ywai9p4b4pah7/artifacts/Hydrogen-1.1.0-win32.exe

Regarding the Midi dialog crash, would you be able to help debug this? I have no way to reproduce this on my own.

If you enable 'Debug' logging before hitting OK, Hydrogen will log useful information to %HOME%\hydrogen\hydrogen.log

If you could grab that and attach here, that would be incredibly helpful. Many thanks!

[MythicMike]

Hello,

Many thanks for the in-development 32 bits version, I will try it.

Regarding midi crash issue, of course I can help you. The configuration used remains the same than the one described in my previous post, did not yet had the time to test on various PC configs.

• 1°/ As a reference, I made some tries with the official latest release (v1.1.0, september 2021), no issue encountered using midi. I attach here the debug reference. MLO_20211012_V1.1.0_Sept2021_32bits_hydrogen.log

-2°/ Some tests with the InDev version 64 bits (03 October 2021). a°/ When a midi device (e.g. a midi keyboard) is connected to the PC and is on, the application crashes during its boot, not possible to lauch it. b°/ To correct this, I must so, set off the midi key board, and after launch Hydrogen, then quit Hydrogen, set on the midi key board an then re-launch Hydrogen. Then, when I select the midi keyboard in the parameters and validate it, the application crashes when I believe it tries to reboot the audio card.

Retrieve attached the related debug report MLO_20211012_Hydrogen_v1.1.0_InDevVersion_64bits.log :

Hoping it will help

Brs

Michel

[MythicMike]

Hello again,

Just tried the InDev 32bits version, no issue regarding Midi Device with this version. The matter seems to appear only on the 64 bits version. In addition, regarding the functional aspect, it works like the InDev 64bits version, with the same the parameters then the ones I previously tested and documented here

Brs

Michel

[MythicMike]

I tried the InDev 1.1.0 version (32 bits) on the smallest PC config I own (i.e. HP mini 210-3000, intel Atom N750 1.67Ghz, 2 GO Ram, Windows 7 Starter 32 bits) and this version seems to work well on it. Using Port Audio, Windows Direct Sound on the principal audio device, the lowest value I need to configure to avoid sound degradation is 707, the audio system information debug windows returns an estimated latency of 707, with a buffer size of 8192 and sample rate of 44100.

The connection with a midi keyboard works well, no application crash until now.

Need to test it with my eDrum in order to see the behavior in living play.

Brs

Michel

[cme]

Thanks for the logs, Michel. It looks like it's likely it's the PortMidi interface that's crashing, not Hydrogen's own code, so I'll review code there to see if I can see anything that's a likely cause. I might have to build an instrumented Hydrogen+PortMidi for you to run in order to work out what's going on.

A couple of questions:

• is this reproducible with diffent MIDI devices? Or just one specific?
• is it (or, are they) directly attached by USB?

Thanks!

[MythicMike]

Good evening,

I did not yet tested the InDev 1.1.0 64bits version (03 October 2021) with my eDrum, but I can give you some additional information regarding the Hardware config on which the crash issue is present:

• PC :
• • CPU Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz 2.50 GHz
• • RAM 12,0 Go
• • Windows : 10 64bits, version 2021H1
• Midi keyboard:
• • Akai MPK mini
• • Plug & Play

I use an externally powered 3.0 UBS hub to connect the midi keyboard to my PC on the USB 3.0 port.

Please note that the issue is only present on the InDev 1.1.0 64bits version (03 October 2021), the issue I described in my previous comments is not present on the InDev 1.1.0 32 bits version.

Brs

Michel

[cme]

Ah I have an LPK25 with any luck it might be similar enough that I could reproduce if I can find a real Windows machine to hook it up to!

[MythicMike]

Good evening,

I did some live test tests with my eDrum and hydrogen and I noticed the following events.

PC configuration:

• Dell Lattitude, Core I5 6300 2.5Ghz - 8 GO Ram, Windows 10 Enterprise 64 bits

eDrum Configuration:

• integration of 2 different edrums:
• • 1°/ XM eDrum 110S (not really known taiwan manufacturer), midi module + 1 bassdrum, 1 snare, 1 hithat, 2 cymbals, 3 toms
• • 2°/ Roland TD-V6X VDrum, midi module + 1 bassdrum, 1 snare, 1 hithat, 2 cymbals, 3 toms
• The modules are connected using midi ports as following:
• • XM eDrum 110S midi output to Roland TD-V6X VDrum midi input
• • Roland TD-V6X VDrum midi output to PC USB (direct connection)
• • Roland TD-V6X VDrum in configured in midi Through mode to allow transmission of XM eDrum 110S midi messages.
• Using only the modules as in regular use (i.e. sound output from the modules) all is working fine, no sound delay, no lost of play.
• Using the configuration described above when connected to the PC and using Hydrogen as 'midi module' and sound generator:
• • When the midi signal is triggered by, and coming from the XM eDrum 110S (through the Roland), no issue, you can play as fast as you can with 2 feet and 2 arms, all is ok.
• • When the midi signal is triggered by, and coming from the Roland TD-V6X VDrum, it is another story. In this case, not possible to play 2 sounds simultaneously. For example, you cannot play bass drum (at tempo) and doing fast roll on the snare --> or the snare sound stop and the bass drum continue to play, or the bass drum sound stop and the snare continues to play, or the both stop. I tried on other pads (e.g. toms and cymbal) and I observed the the same issue.

In term of play and latency feeling, I've tried last official V1.1.0 release (32 bits) and InDev V1.1.0 version (32 bits):

• the last official V1.1.0 release (32 bits) seems to be a little bit more reactive, more natural and more pleasant so than the InDev V1.1.0 version (32 bits).
• In terms of parameters:
• • last official V1.1.0 release (32 bits) --> buffer size 512, sample rate 44100
• • InDev V1.1.0 version (32 bits) --> latency (targeted and estimated) 707 frames, buffer size 8192, sample rate 44100.

Hoping it continues to help your software design and development.

Brs

Michel

[MythicMike]

Good evening,

In order to complete the description of the midi issue encountered on the Roland module described in my previous post , you will retrieve 2 log files (debug mode):

• 1 indicating some midi events from the XM module (hydrogen_XM_2Toms_001.log),
• 1 indicating some midi events from the Roland module (hydrogen_Roland_Snare+Tom_001.log).

The test done is very simple as it consists to play simultaneously 2 instruments. In instance 2 toms on XM and snare + tom on the Roland.

In the XM module log file, the midi numbers are 46 for 1 tom and 45 for the second one. When I did the test, no issue encounter at all, the 2 sounds are played simultaneously without any problem.

In the Roland module log file, the midi numbers are 38 for the snare and 48 for the tom. When I did the test, not possible for hydrogen to play the 2 sounds at the same time: only the snare, only the tom or none of the two at all. When I read the log file it seems that not all the midi events are recorded as I do not have the same numbers of tom's midi identifiers (48) and the snare ones (38). In instance, 5 snares versus 3 toms even if I played simultaneously snare and toms.

I tried to change some parameters in the midi section of the Roland module (such as sync mode, midi channel, GM mode, ...) : no change, the issue remains.

I noted also that the modules (XM and Roland ones) are configured on the channel 10, but the channel number registered in the log files is 9.

Best regards

Michel

hydrogen_XM_2Toms_001.log hydrogen_Roland_Snare+Tom_001.log

[cme]

So... now that I finally got round to being able to attach my LPK25 to a Windows VM, it turns out that the issue is, in fact, that PortMIDI is just broken for 64-bit Windows. Mingw integrate directly from the abandonware "official" release. I could fix in a patch for MinGW, or we could fork and maintain, or suggest MinGW take a look at maybe using @mixxxdj 's fork which seems to be somewhat actively maintained.

[theGreatWhiteShark]

That doesn't sound too promising. But we shouldn't be the only ones affected either. I haven't looked into MinGW etc. yet but I just checked that Audacity supports PortMIDI too. Maybe they found a workaround.

we could fork and maintain

That sounds scary

[cme]

Joy, it looks like there was actually a fixed release (though I haven't found an anouncement anywhere, just a tarball on sourceforge) it's just not been picked up in MSYS. I'll see about fixing that :)

[cme]

PR against MSYS2, for the record.

[cme]

MSYS2 have applied the patch and the updated portmidi is now in the MSYS2 that we're picking up for Appveyor builds. The audio issues are addressed by #1388 , so I'm closing now :)

[MythicMike]

Good evening,

Thank you for the update.

I did no yet had the chance to test the new release with my e-drum configuration but I will do it in the coming weeks.

Brs

Michel