• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: why would a plugin be running SRC? threading rules?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why would a plugin be running SRC? threading rules?


  • Subject: Re: why would a plugin be running SRC? threading rules?
  • From: tahome izwah <email@hidden>
  • Date: Sun, 10 Jan 2010 22:49:18 +0100

Looks like the output sample rate and rate of the the file/stream that
you're playing don't match. I think the SRC happens in the
SystemOutputAU not AUGraphicEQ.

--th

2010/1/10 Paul Davis <email@hidden>:
> this is a trace of ardour running the apple graphic EQ plugin. i'm
> curious about why this plugin would be running SRC internally ... any
> ideas? the only justification i could think of was something like
> upsampling for "improved quality", but this seemed unlikely to me.
>
> in addition, i get the impression that there are some implicit thread
> rules being violated by ardour. the trace below shows the plugin being
> deactivated, but from a thread other than the RT/Audio/process thread
> that would be calling render. i know that the RT/Audio/process thread
> is not active when this happening, but is there something i missed in
> the AU spec that says that you shouldn't be crossing thread boundaries
> like this?
>
> 0   ...pple.audio.units.Components      0x700164c8
> AUSampleRateConverterEntry + 952
> 1   ...pple.audio.units.Components      0x7004006a SystemOutputAUEntry + 2762
> 2   ...pple.audio.units.Components      0x7005abbe AUGraphicEQEntry + 46
> 3   ...ple.CoreServices.CarbonCore      0x95dfb935 CallComponentDispatch + 29
> 4   ...apple.audio.units.AudioUnit      0x93099aa1 AudioUnitReset + 49
> 5   libardour.dylib                     0x134bf0f9
> CAAudioUnit::GlobalReset() + 41 (CAAudioUnit.h:154)
> 6   libardour.dylib                     0x133fedf2
> ARDOUR::AUPlugin::deactivate() + 28 (audio_unit.cc:702)
> 7   libardour.dylib                     0x1333ea7e
> ARDOUR::PluginInsert::deactivate() + 60 (insert.cc:273)
> 8   libardour.dylib                     0x133861f0
> ARDOUR::Route::flush_redirects() + 84 (route.cc:2465)
> 9   libardour.dylib                     0x133df688
> ARDOUR::Session::flush_all_redirects() + 84 (session_transport.cc:655)
> 10  libardour.dylib                     0x133e2e8e
> ARDOUR::Session::non_realtime_stop(bool, int, bool&) + 1320
> (session_transport.cc:415)
> 11  libardour.dylib                     0x133e3c25
> ARDOUR::Session::butler_transport_work() + 1221
> (session_transport.cc:271)
> 12  libardour.dylib                     0x13396e0a
> ARDOUR::Session::butler_thread_work() + 1068 (session_butler.cc:243)
> 13  libardour.dylib                     0x1339789c
> ARDOUR::Session::_butler_thread_work(void*) + 172
> (session_butler.cc:161)
> 14  libSystem.B.dylib                   0x925c2155 _pthread_start + 321
> 15  libSystem.B.dylib                   0x925c2012 thread_start + 34
>  _______________________________________________
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: why would a plugin be running SRC? threading rules?
      • From: Paul Davis <email@hidden>
References: 
 >why would a plugin be running SRC? threading rules? (From: Paul Davis <email@hidden>)

  • Prev by Date: why would a plugin be running SRC? threading rules?
  • Next by Date: Re: why would a plugin be running SRC? threading rules?
  • Previous by thread: why would a plugin be running SRC? threading rules?
  • Next by thread: Re: why would a plugin be running SRC? threading rules?
  • Index(es):
    • Date
    • Thread