AudioTrack: thread safety of operations?

[Tamás Kovács]

The documentation says that AudioTrack.write() is thread-safe in terms of
stop().

What about the other operations? As far as I can see, e.g. play() and
pause() should also be callable from another thread.

write() is blocking, so it does not make much sense to call pause() from
the same thread as write().

Is it OK to use an own thread for write() and using the other operations
(stop, pause, play) from a different thread?

[Lew]

Post by Tamás Kovács
The documentation says that AudioTrack.write() is thread-safe in terms of
stop().
What about the other operations? As far as I can see, e.g. play() and
pause() should also be callable from another thread.
write() is blocking, so it does not make much sense to call pause() from
the same thread as write().
Is it OK to use an own thread for write() and using the other operations
(stop, pause, play) from a different thread?

Nearly always, absence of a promise of thread safety is equivalent to a
promise of thread unsafety.

This is more likely given the care to specify that 'write()' "is thread
safe with respect to stop()<../../../reference/android/media/AudioTrack.html#stop()>
calls"
specifically. IOW, if it was thread safe for other calls they'd've said so.

We go by the docs, too, so we're unlikely to give you a different answer
than the Javadocs do.
--
Lew

[Tamás Kovács]

OK, thanks. So you're basically saying that if I want to call e.g.
pause()+flush() on an AudioTrack, I need to guarantee that write() is
atomic in terms of my pause() and flush() call, right?

To be brief, (per the docs), only a stop() call is allowed to execute
while a write() is in progress. Is this correct?

Post by Lew

Post by Tamás Kovács
The documentation says that AudioTrack.write() is thread-safe in terms of
stop().
What about the other operations? As far as I can see, e.g. play() and
pause() should also be callable from another thread.
write() is blocking, so it does not make much sense to call pause() from
the same thread as write().
Is it OK to use an own thread for write() and using the other operations
(stop, pause, play) from a different thread?

Nearly always, absence of a promise of thread safety is equivalent to a
promise of thread unsafety.
This is more likely given the care to specify that 'write()' "is thread
safe with respect to stop()<../../../reference/android/media/AudioTrack.html#stop()>
 calls"
specifically. IOW, if it was thread safe for other calls they'd've said so.
We go by the docs, too, so we're unlikely to give you a different answer
than the Javadocs do.
--
Lew

[Tamás Kovács]

And what about e.g. setStereoVolume() ?
It sounds a bit strange that the current write() operation must finish
before setStereoVolume() can be called, but if you say so.

Post by Tamás Kovács
OK, thanks. So you're basically saying that if I want to call e.g.
pause()+flush() on an AudioTrack, I need to guarantee that write() is
atomic in terms of my pause() and flush() call, right?
To be brief, (per the docs), only a stop() call is allowed to execute
while a write() is in progress. Is this correct?

Post by Lew

Post by Tamás Kovács
The documentation says that AudioTrack.write() is thread-safe in terms of
stop().
What about the other operations? As far as I can see, e.g. play() and
pause() should also be callable from another thread.
write() is blocking, so it does not make much sense to call pause() from
the same thread as write().
Is it OK to use an own thread for write() and using the other operations
(stop, pause, play) from a different thread?

Nearly always, absence of a promise of thread safety is equivalent to a
promise of thread unsafety.
This is more likely given the care to specify that 'write()' "is thread
safe with respect to stop()<../../../reference/android/media/AudioTrack.html#stop()>
 calls"
specifically. IOW, if it was thread safe for other calls they'd've said so.
We go by the docs, too, so we're unlikely to give you a different answer
than the Javadocs do.
--
Lew

[Tamás Kovács]

Anyone? (to the last but one question, even)

Thanks in advance

Post by Tamás Kovács
And what about e.g. setStereoVolume() ?
It sounds a bit strange that the current write() operation must finish
before setStereoVolume() can be called, but if you say so.

Post by Tamás Kovács
OK, thanks. So you're basically saying that if I want to call e.g.
pause()+flush() on an AudioTrack, I need to guarantee that write() is
atomic in terms of my pause() and flush() call, right?
To be brief, (per the docs), only a stop() call is allowed to execute
while a write() is in progress. Is this correct?

Post by Lew

Post by Tamás Kovács
The documentation says that AudioTrack.write() is thread-safe in terms of
stop().
What about the other operations? As far as I can see, e.g. play() and
pause() should also be callable from another thread.
write() is blocking, so it does not make much sense to call pause() from
the same thread as write().
Is it OK to use an own thread for write() and using the other operations
(stop, pause, play) from a different thread?

Nearly always, absence of a promise of thread safety is equivalent to a
promise of thread unsafety.
This is more likely given the care to specify that 'write()' "is thread
safe with respect to stop()<../../../reference/android/media/AudioTrack.html#stop()>
 calls"
specifically. IOW, if it was thread safe for other calls they'd've said so.
We go by the docs, too, so we're unlikely to give you a different answer
than the Javadocs do.
--
Lew