Interesting. Could be either. On the one hand, if you had a process
doing disk I/O and suspended it, that process shouldn't suspend all disk
I/O in the whole system. So it seems like the sound I/O process isn't as
robust if a single process can lock it down so nothing else can use it.
That said, sound wasn't usually considered as mission critical as disk
operations. You can eliminate the questions about SoX and MacPorts when
reporting to Apple by using the built-in say command. Do a "say" and a
long string of text. Interrupt it (control+z) and you'll lose all sound
throughout the system. Do an "fg" to bring it back to the foreground and
all will be well again. Seems like flaw to me albeit an understandable
one that probably won't effect a lot of users. Leave it to Doug Lee to
find something like this :)
CB
On 11/10/11 4:02 PM, Doug Lee wrote:
Not sure if this is a MacOS problem, a SoX problem, or both.
Tested on MacOS SnowLeopard (and Leopard I think, but I'm not sure of
that) with SoX 14.3.2 as installed via MacPorts.
Problem: I can block all sounds on MacOS by suspending a SoX play.
Steps to reproduce:
Verify that system sounds work: Cause a beep by hitting an invalid
key, play a file with another program, etc.).
Start playing a file (play file.wav) from a shell (I use tcsh).
Suspend play with Ctrl+Z.
Try to produce a sound with another program.
Result: No program, even the system itself (or VoiceOver, for those of
us who use that) can produce a sound until play is resumed.
--
You received this message because you are subscribed to the Google Groups
"MacVisionaries" group.
To post to this group, send email to macvisionaries@googlegroups.com.
To unsubscribe from this group, send email to
macvisionaries+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/macvisionaries?hl=en.
