Calling Drambo developers: Export audio issue with MU Waverley (moodunits AUs)

Hi,

Rob, moodunits developer here. I'm seeing a strange issue with export audio and my instrument AU, Waverley. Curiously not all users are affected, but I'm able to reproduce the issue on iOS 14.4.

It looks to me like when you Export audio (either song or current pattern) you end up with an audio file corresponding to the length of the pattern, but it is totally silent, or will have a kick drum if the metronome is enabled.

The really odd thing is, I would normally expect to receive a whole load of initialisation and preparation before the render (*), but I get literally nothing from Drambo during the export process as far as I can tell from my own debug. I was not expecting that at all!

(*) For the techie-inclined, there's a whole bunch of stuff that usually gets called prior to an offline render, resources deallocated, reallocated (several times in the cases of some hosts...) plus the odd AudioUnit reset for good measure. When I do the Drambo export, I don't see any of that stuff.

Any idea what could be causing this and why export seems to be working OK for some and not for others / me?

Thanks, -Rob

«1

Comments

  • @giku

    Verified that on 13.7 and 14.4.

    13.7: works as expected - no problem.

    14.4: correct file length (time based) but silent on latest Drambo beta 1.33 (7)

    Another weird iOS14 thing.

  • Many thanks for the investigation @MrBlaschke !

  • edited March 5

    Hi,

    Why are you expecting a whole load of initialization and preparation of already allocated and initialized AudioUnit? Bouncing is like audio rendering, audio unit gets the same input and calls.

    Regarding specs:

    The only thing that I should do, to cut possible long tails is calling reset , but it has probably nothing to do with our case. This will be fixed.

    There is an optional offlineRendering property as well "An audio unit may respond by using a more expensive signal processing algorithm, or allowing itself to block at render time if data being generated on secondary work threads is not ready in time.", but its just a flag.

    Do you know anything more from your debugging session? (it's out of my scope)

    Did you check if actual audio signal lands in audio buffer? I assume your AU doesn't crash and audio comes back once offline rendering is finished?

  • edited March 5

    @giku - I was expecting a "whole load of initialisation" as that's what all the other hosts I've looked at do, prior to an offline render. They all do it slightly differently, but generally there's a deallocation and reallocation and a reset. GarageBand does this, Cubasis does this, Auria does this...

    I also render differently according to whether the render is offline or not. I'm guessing that's why other hosts do the (re)initialisation and then capture the render block again or whatever.

    I debug pretty much every method and property access on my AU and when exporting audio from Drambo, I literally see nothing. I will double-check to see if there is more debug I can add.

    Weird that it works fine in iOS 13.7 and not in 14.4. I can confirm that a few spot tests and audio export, track merging, freezing etc., seems to work OK in the other usual suspect AU hosts.

    I can confirm my AU does not crash and seems to be functioning fine after the audio export with no audio in it.

  • edited March 5

    Just check with NSLogging the final stage... if audio lands in the buffer given by a render block (e.g. first sample value of each frame).. this will tell us if its my/iOS side or yours..

    Other possible reasons: you are not receiving midi, or you use system time to offset midi notes / audio stuff (not host time provided in a block).

    As about reinitialization I don't see any reason for that - specs say nothing about that.

    Of course this may be something in Drambo, but only ou can find it :)

  • edited March 5

    I'm not even seeing anything being pulled from my render block when rendering offline from Drambo.

    Regarding initialisation... I have no idea why the other guys (including Apple) do this, but it's what I have observed. You would need to ask the Cubasis developers, or the Auria developers or the GarageBand developers...

    My guess is that AU is such a flakey mess that they all do it to be "on the safe side". As I've mentioned, everyone seems to do it differently and / or in a slightly different sequence and it's been a pain point for me working around all these different approaches.

    One thing's for sure - your approach is different from everything else I've seen before so I guess I'm going to have to come up with a workaround somehow, and / or quite possible that it's an edge case / error condition in my code that your "unique" approach has exposed.

    If there's a spec that details how all this should be done, please share! I certainly haven't seen anything from Apple on the sequence of events that you should expect to see (if any) prior to an offline render. I'm just trying to handle as best I can what I see.

  • PS. I'm pretty sure you're not setting the isRenderingOffline flag during audio export (?) but you probably should.

  • Im gonna check this as well. The weirdest thing is that other units work.

  • @moodunits

    My guess is that AU is such a flakey mess that they all do it to be "on the safe side". As I've mentioned, everyone seems to do it differently and / or in a slightly different sequence and it's been a pain point for me working around all these different approaches.

    There's some truth in that for sure and then we have iOS 14 on top 🤭

  • edited March 5

    Thanks @giku. Well, everyone's doing it differently I guess... 😐️

    Speaking of which... I wonder if you decide to call reset() on the AU you might also find the need to do the re-init stuff the other hosts do.

    For example, when rendering / freezing a track in Cubasis, here is the sequence of events:

    render resources deallocated

    rendering offline flag set to true

    render and event blocks accessed (get)

    render resources allocated

    output busses (get)

    reset called (multiple times...)

    *** DO ACTUAL RENDER ***

    then there's a similar sequence to deallocate / reallocate after the render is done setting the flag to false for the offline render.

    All the other hosts I've looked at do similar stuff, but not identical.

    I'm not saying which is right or wrong (and I think the above is pretty crazy), and ultimately other AUs work fine in Drambo (as did mine on iOS 13.7 it seems...) but even Apple do something similar when merging tracks in GarageBand - calls reset() more often, but not multiple times in succession. GB calls reset just before the resource deallocate, then again after the render.

    It's weird, messed-up and makes me sad.

  • I should have maybe asked you for the same before I bought Drambo as yours is 4x more expensive. Didn't hurt as much as having to buy Auria Pro to debug another rendering issue 😀

    Here you go: @giku - FY6KN9J3MAXH (Don't anyone else steal this!)

    I'm still digging, but I'm not getting very far I'm afraid other than I suspect the issue may be lurking in an Apple AU that I use which could possibly explain the iOS 14.x vs. 13.7 issue.

  • Got it, thanks

  • edited March 5

    Yes, as its a public users forum, I would rather expect you to drop me an email, ask for a redeem code and discuss our dev-dev issues in a safe place ;) .. thats how it usually works, but I like outsiders :) .. you don't need to buy hosts usually..

    Let me know if you want a redeem code.

  • ^^

    You know you can send private messages in this forum to each other?

    😄

  • edited March 5

    Sometimes having developer discussions publicly viewable (to other developers, current or would-be), for example Apple Developer Forum, Stack Overflow is useful... but I'm happy to do either. Give a man a fish, and all that... A dedicated dev forum would be perhaps ideal.

    Anyone who's done AU dev work has probably spent huge amounts of time scratching around for info. Putting these sort of "gotchas" out there (if that's what it is) might save someone some time.

    Apologies to anyone who's irritated by this, but you probably haven't spent all day looking at the issue either. I'll DM @giku here on in if need be.

  • @moodunits

    Welcome to the wildness of the dRambo forum.

    Hiya. 🥳

  • Agreed @moodunits Apple AU developer’s forum might end up being a place where some kind of consensus is found with lack of leadership from Apple.

  • @moodunits

    It’s good that you pointed this out, humour aside.

    One of the things that I like here on this

    forum is that we all try to assist each other.


    By the way Auria Pro has problems with rendering

    dRambo on iOS 14.3 which I’ve communicated to

    the Auria Pro Dev so something to bear in mind I think.

  • @moodunits

    Sometimes having developer discussions publicly viewable (to other developers, current or would-be), for example Apple Developer Forum, Stack Overflow is useful... but I'm happy to do either. Give a man a fish, and all that... A dedicated dev forum would be perhaps ideal.

    I'm quite interested in these discussions as I'm generally interested in development matters and I'm beta testing other apps as well. In a few cases, I've been able to connect developers in regards to certain issues that can be hard to solve (mostly for the lack of detailed documentation and examples from Apple). Not sure how many here share this interest though 😄

  • Yes I agree developers forum is a good place :)

  • Is there such a forum for IOS devs? I wonder if Michael at AB would be willing to add a private forum at audiobus. Seems like it’d be as good a hub as any for the developers.

    of course, that should be invisible to non-developer accounts.

  • @aleyas It already exists since quite a long time:


  • shows how much I know hahaha 😅 Cheers @rs2000

  • Interestingly enough I did know about the developers section on the Audiobus Forum.

    I’m not a developer so I didn’t join.

Sign In or Register to comment.