Encoding monoliths broken

[d.healey]

Encoding a monolith causes HISE to crash and disabling the sample map ID check and the normalisation completely cleared out my sample map xml - luckily I had a backup.

I tried with both new_layout and master branch. Anyone know a commit that allows you to encode without crashing?

[d.healey]

This post is deleted!

[d.healey]

I think it's something to do with my audio interface settings. I noticed on my main PC if I tried different soundcard settings it would affect the amount of progress made before it crashed. I just tried it on my Mac Mini and it created the monolith without issue.

[d.healey]

@Christoph-Hart This also affects installing samples so it could be a problem for the end-user as well depending on their audio interface setup.

[d.healey]

I've enabled debug mode in HISE and enabled HLAC_DEBUG_LOG in projucer. Where is the log file written? I don't see it in the HISE appdata folder.

[Christoph Hart]

Can you reproduce it reliably with a particular samplemap?

[d.healey]

@Christoph-Hart Yes, on my main system but no problem on my Mac

[Christoph Hart]

What happens if you run it in the debugger? A reproducible crash should be pretty easy to spot during debugging.

[d.healey]

@Christoph-Hart I did a step through, which took a while because of the number of samples and it seems to break before it writes the file. That was a few days ago so I'll do it again in a little while to refresh my memory and see if I can spot anything.

[d.healey]

I'm seeing lots of this in the output, I don't know what it means...

Also I noticed that certain audio device settings prevent my server calls working, but one problem at a time.

[Christoph Hart]

This output looks ok, it's just super verbose to track down codec issues, but I don't think that is the case here, but some more trivial file I/O problem. I think you can deactivate the logging and just wait until the debugger crashes to inspect the stack trace.

[d.healey]

@Christoph-Hart Ok, I'll do that now and report my findings.

[d.healey]

It crashes in hise::MonolithExporter::writeFiles() I'm stepping through it now to see if I can get any more detail.

[d.healey]

Ok when I stepped through the entire process it encoded the samples without issue

[d.healey]

I haven't been able to get any further with it. I tried to recreate the issue on Windows by playing around with various audio device settings but no luck. I'm suspecting this is related to my move a to pipewire a few weeks ago, but since pipewire is the future I would definitely like to get it working.

Update: I disabled pipewire, reinstalled jack, and the export worked and then I reenabled pipewire and the export doesn't work.

I see this in the pipewire changelog for the next release Stability and compatibility improvements in JACK apps. So maybe I'll just disable pipewire in HISE for now and see if the update fixes the issue when it arrives.

[d.healey]

I think I've found a partial solution... move to the future I rebuilt HISE without JACK (disabled it in Projucer) and now I can use pipewire as the audio device and the encoding with HLAC seems to work fine.

The only potential issue I see now, but I'll need to test, is when I export my project I will want it to include JACK because most Linux users will be using it, and if they also have pipewire installed I expect the decoding to fail. But I'll cross that bridge when the time comes, or I'll ignore it until someone complains

[ustk]

@d-healey said in Encoding monoliths broken:

I'll ignore it until someone complains

[d.healey]

@ustk I occassionally get a report of a bug in a piece of software I wrote 10 years ago and no-one has noticed. These are the sort of bugs I like

[ustk]

[d.healey]

I've hit another snag. The encoding to monolith works with my previous solution, but extracting from a hr file causes an instant crash. I noticed on Debian that changing the audio driver affected how far the extraction process got before the crash. I've tested the same project on Windows with ASIO and it works fine.