thetechnobear

Ive written a max external which communicates with my Eigenharp directly via USB.

Works fine in Max 6, but in Max 7 there are performance issues, it appears even with Overdrive ON my object is not getting serviced frequently enough.

(note: in Max 6, it works even without overdrive on)

the basics of the external are using clock_fdelay(x->m_clock,0.0) to get a regular clock tick, which pull the data off my queue, which is populated on a different thread servicing USB.

but it appears, that this callback from max is just not happening frequently enough, as it used to in Max6.

also when I activate it, Max7 is struggling to respond to the UI, again something I did not experience in Max6

note: Ive not tried to rebuild or anything, so its using exactly the same external code in both Max6 and 7. (so SDK 6.1.4)

Im a bit at a loss, as to where to start looking for problem/solution...

Hi,
Ive written a max external which communicates with my Eigenharp directly via USB.

Works fine in Max 6, but in Max 7 there are performance issues, it appears even with Overdrive ON  my object is not getting serviced frequently enough.
(note: in Max 6, it works even without overdrive on)

the basics of the external are using clock_fdelay(x->m_clock,0.0) to get a regular clock tick, which pull the data off my queue, which is populated on a different thread servicing USB.
but it appears, that this callback from max is just not happening frequently enough, as it used to in Max6.

Im a bit at a loss, as to where to start looking for problem/solution...


max-7-max-external-performance-issue

(on a positive note, except for the external, the patch that it lives in, seems to be operating very well!)

We would need an example. Please contact support attaching an archive of your patch with any necessary objects, support information, and steps to reproduce. Source code might also help point to any issues.

hmm, not sure how i can send something useful, as Im assuming you don't have an Eigenharp Alpha in the office...

so the external will not initialise due to the lack of USB device.

i guess, I will have to some how dig out some essentials to reproduce in a different scenario, but thats going to take quite a bit of effort.

are there any general pointers you can provide me, where I can dig a little before going through that process?

is clock_fdelay any different? in particular when asking for an immediate callback (i.e. delay = 0)

any changes in the way the scheduler works that might affect externals using clocks.

hmm, not sure how i can send something useful, as Im assuming you don't have an Eigenharp Alpha in the office...
so the external will not initialise due to the lack of USB device.

are there any general pointers you can provide me, where I can dig a little before going through that process?
differences in Max 6 vs 7
e.g.
is clock_fdelay any different? in particular when asking for an immediate callback (i.e. delay = 0)
any changes in the way the scheduler works that might affect externals using clocks.


Big changes in the scheduler FWIW, but it should be working better. There are some threading issues for very rare circumstances where we could miss scheduler events (we only received one example so far just a few days before release), and the scheduler stalls for 100ms at a time. That could be what you're seeing. If you post when your clocks are executing and you see them in batches separated in time like that when they shouldn't be, that would indicate the issue.

We have what we believe to be a solid fix for this in a forthcoming 7.0.1 already, but it wasn't tested enough to make it into version 7.0.0. So if that's the case stay tuned. However, if you are able to strip things down better in a way we could evaluate your issue (e.g. simulate your USB reading with dummy data that also has the same problem or similar), that would be helpful.

hmm, that could be indicative of what I'm seeing... as generally its processing the USB ok, but then every not and then it seems to have not processed the messages, then I reinitialise all seems ok for a short while, and then bang it happens again.

I'll put in some logging which reports avg/max time between callbacks.

I assume if this is in the scheduler, then i wont see any difference if I move away from using clock_fdelay over to qelems.

hmm, that could be indicative of what I'm seeing... as generally its processing the USB ok, but then every not and then it  seems to have not processed the messages, then I reinitialise all seems ok for a short while, and then bang it happens again.
I'll put in some logging which reports avg/max time between callbacks.

I assume if this is in the scheduler, then i wont see any difference if I move away from using clock_fdelay over to qelems.


Actually, yes you will see a difference as the queue doesn't have any relationship to the scheduler. If that also solves your issue, it might point to similar.

i did some initial testing yesterday with timing…

and its a big surprise (to me… and i do need to double check/verify), in a good way :)

it appears that I'm getting called back MUCH more frequently that I used to, I'm assuming down to the improved scheduler you have mentioned here and elsewhere.

What is strange, is that this is causing my code to take longer to execute, I suspect (and will test today) that this is because its raising the cpu load to an extent where its trashing, or perhaps even OSX is reducing its thread priority. This is just a suspicion, but I will test by throttling the workload.

I might also see if qelems work differently/better… in Max 6 I saw little difference, but perhaps in Max 7 it might.

I'll post an update, when I get more definitive results.

i did some initial testing yesterday with timing…
and its a big surprise (to me… and i do need to double check/verify), in a good way :)
it appears that I'm getting called back MUCH more frequently that I used to, I'm assuming down to the improved scheduler you have mentioned here and elsewhere.
What is strange, is that this is causing my code to take longer to execute, I suspect (and will test today) that this is because its raising the cpu load to an extent where its trashing, or perhaps even OSX is reducing its thread priority. This is just a suspicion, but I will test by throttling the workload.

I'll post an update, when I get more definitive results.


the change in the scheduler behaviour was causing me two issues:

a) on initialisation of my external, clock_fdelay(x->m_clock,0.0), now causes an almost instant callback,

this caused issues a timing issue for me, as initialisation was not fully complete. in max6, the less responsive scheduler meant it was completed.. this initialisation issue introduced more load on the regular tick.

b) on the regular tick i created using clock_fdelay(x->m_clock,0.0), it is called so often now in Max7 that some of the processing done, was raising cpu to levels, to a point they became detrimental. this was exacerbated by the init issues from (a)

so no issue with Max7, and in fact the improved scheduler will be beneficial, but some externals may find they need to optimise there behaviour in scheduler callbacks.

Positive: I love the fact that Max7 can be loaded up properly in Xcode now, rather than having to use the Max runtime, makes debugging externals MUCH easier :)

Negative: I seem to be getting more memory corruption and SIGABRT that I don't get in Max6... these always arise in the max threads... of course it could be caused by my external, though most of this code is also used outside of max without issue.

any tips on tracking down the source of these issues would be greatly appreciated :)

also, is it possible to turn off crash recovery from the command line? (so i don't have the message when using the debugger)

ok, confirmed...
the change in the scheduler behaviour was causing me two issues:
a) on initialisation of my external, clock_fdelay(x->m_clock,0.0), now causes an almost instant callback,
this caused issues a timing issue for me, as initialisation was not fully complete. in max6, the less responsive scheduler meant it was completed.. this initialisation issue introduced more load on the regular tick.
b) on the regular tick i created using clock_fdelay(x->m_clock,0.0), it is called so often now in Max7 that some of the processing done, was raising cpu to levels, to a point they became detrimental. this was exacerbated by the init issues from (a)

a couple of things:
Positive: I love the fact that Max7 can be loaded up properly in Xcode now, rather than having to use the Max runtime, makes debugging externals MUCH easier :)

Negative: I seem to be getting more memory corruption and SIGABRT that I don't get in Max6... these always arise in the max threads... of course it could be caused by my external, though most of this code is also used outside of max without issue. 

also, is it possible to turn off crash recovery from the command line? (so i don't have the message when using the debugger)


Max 7 : max external performance issue :(