• 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: Coreaudio Deadlock
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coreaudio Deadlock


  • Subject: Re: Coreaudio Deadlock
  • From: Derk-Jan Hartman <email@hidden>
  • Date: Thu, 2 Jun 2005 15:01:02 +0200

I have found a stack corruption in VLC that i'm pretty sure now was responsible for triggering these deadlock situations. Apparently these locks happened to be very near to the memory of the corruption or something, because i haven't seen the problem since fixing the stack corruption.

Much thanks to all for your care though :D
The module now almost fully supports, multichannel discrete analog audio. Only several smaller issues remain.


DJ


On 01 jun 2005, at 23:59, Jeff Moore wrote:

I looked at the back traces and here's what I see:

Thread 1 is blocked trying to lock an internal VLC lock.
Thread 6 looks quiescent.
Thread 7 is blocked trying to synchronize with the IO thread before proceeding to remove the IOProc.


Without seeing what the rest of the threads are up to, it's pretty hard to say how or why the dead lock is taking place, especially the IO thread. I imagine that it is probably blocked holding onto one or more of the locks that Threads 1 and 7 are trying to locked. If I had to guess, I would look hard at the lock that Thread 1 is trying to lock. It seems the most likely culprit.

On Jun 1, 2005, at 1:40 PM, Derk-Jan Hartman wrote:

I find myself in a deadlock situation with the VLC coreaudio renderer.
http://pastebin.com/293456

basically the mainthread updates the interface and asks for the volume from the audio output thread. But when the auhal module is still working on updating itself and calls the CA lock, it apparently deadlocks.

Now i'm not saying that locking the mainthread is something we usually do, but i would have thought the coreaudio system to have been more robust then this.

Is it really so sensitive to things like this?

DJ
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://www.sidequest.org

--


Jeff Moore
Core Audio
Apple


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden


---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://www.sidequest.org

_______________________________________________
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


References: 
 >Coreaudio Deadlock (From: Derk-Jan Hartman <email@hidden>)
 >Re: Coreaudio Deadlock (From: Jeff Moore <email@hidden>)

  • Prev by Date: Re: AppleFWAudio source open?
  • Next by Date: Re: AudioUnit write-only parameter (Was: Cocoa Generic View)
  • Previous by thread: Re: Coreaudio Deadlock
  • Next by thread: Re: Coreaudio Deadlock
  • Index(es):
    • Date
    • Thread