Is DataLine.getMicrosecondPosition() thread-safe?
up vote
0
down vote
favorite
Let's say I use DataLine.write() in one thread and read DataLine.getMicrosecondPosition() in another. Will the reader thread see the updates of the writer thread, or should I synchronize my code to guarantee visibility?
java thread-safety javasound
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
add a comment |
up vote
0
down vote
favorite
Let's say I use DataLine.write() in one thread and read DataLine.getMicrosecondPosition() in another. Will the reader thread see the updates of the writer thread, or should I synchronize my code to guarantee visibility?
java thread-safety javasound
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Let's say I use DataLine.write() in one thread and read DataLine.getMicrosecondPosition() in another. Will the reader thread see the updates of the writer thread, or should I synchronize my code to guarantee visibility?
java thread-safety javasound
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
Let's say I use DataLine.write() in one thread and read DataLine.getMicrosecondPosition() in another. Will the reader thread see the updates of the writer thread, or should I synchronize my code to guarantee visibility?
java thread-safety javasound
java thread-safety javasound
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
asked Nov 19 at 8:38
Markus Malkusch
5,3722150
5,3722150
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39
add a comment |
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
Just to be clear:
write() is a potentially blocking call that puts data into the line's buffer for rendering. I.e. the line may render the data at some time in the future. From the docs:
The requested number of bytes of data are read from the specified array, starting at the given offset into the array, and written to the data line's buffer.
getMicrosecondPosition () tells you how many microseconds have already been rendered, docs:
The microsecond position measures the time corresponding to the number of sample frames captured by, or rendered from, the line since it was opened.
Both methods should be thread-safe, as there is no warning in the Javadocs.
answered Nov 19 at 8:51
hendrik
1,430821
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but ifgetMicrosecondPosition()was only returning correct values, if called from the same thread aswrite()or from within sync, I would expect this to be worth a note in the javadocs. Especially, aswrite()just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining themicrosecondPositionvalue. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation incom.sun.media.sound.DirectAudioDeviceis synchronized.
– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
Just to be clear:
write() is a potentially blocking call that puts data into the line's buffer for rendering. I.e. the line may render the data at some time in the future. From the docs:
The requested number of bytes of data are read from the specified array, starting at the given offset into the array, and written to the data line's buffer.
getMicrosecondPosition () tells you how many microseconds have already been rendered, docs:
The microsecond position measures the time corresponding to the number of sample frames captured by, or rendered from, the line since it was opened.
Both methods should be thread-safe, as there is no warning in the Javadocs.
answered Nov 19 at 8:51
hendrik
1,430821
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but ifgetMicrosecondPosition()was only returning correct values, if called from the same thread aswrite()or from within sync, I would expect this to be worth a note in the javadocs. Especially, aswrite()just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining themicrosecondPositionvalue. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation incom.sun.media.sound.DirectAudioDeviceis synchronized.
– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
add a comment |
up vote
0
down vote
Just to be clear:
write() is a potentially blocking call that puts data into the line's buffer for rendering. I.e. the line may render the data at some time in the future. From the docs:
The requested number of bytes of data are read from the specified array, starting at the given offset into the array, and written to the data line's buffer.
getMicrosecondPosition () tells you how many microseconds have already been rendered, docs:
The microsecond position measures the time corresponding to the number of sample frames captured by, or rendered from, the line since it was opened.
Both methods should be thread-safe, as there is no warning in the Javadocs.
answered Nov 19 at 8:51
hendrik
1,430821
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but ifgetMicrosecondPosition()was only returning correct values, if called from the same thread aswrite()or from within sync, I would expect this to be worth a note in the javadocs. Especially, aswrite()just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining themicrosecondPositionvalue. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation incom.sun.media.sound.DirectAudioDeviceis synchronized.
– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
add a comment |
up vote
0
down vote
up vote
0
down vote
Just to be clear:
write() is a potentially blocking call that puts data into the line's buffer for rendering. I.e. the line may render the data at some time in the future. From the docs:
The requested number of bytes of data are read from the specified array, starting at the given offset into the array, and written to the data line's buffer.
getMicrosecondPosition () tells you how many microseconds have already been rendered, docs:
The microsecond position measures the time corresponding to the number of sample frames captured by, or rendered from, the line since it was opened.
Both methods should be thread-safe, as there is no warning in the Javadocs.
answered Nov 19 at 8:51
hendrik
1,430821
Just to be clear:
write() is a potentially blocking call that puts data into the line's buffer for rendering. I.e. the line may render the data at some time in the future. From the docs:
The requested number of bytes of data are read from the specified array, starting at the given offset into the array, and written to the data line's buffer.
getMicrosecondPosition () tells you how many microseconds have already been rendered, docs:
The microsecond position measures the time corresponding to the number of sample frames captured by, or rendered from, the line since it was opened.
Both methods should be thread-safe, as there is no warning in the Javadocs.
answered Nov 19 at 8:51
hendrik
1,430821
answered Nov 19 at 8:51
hendrik
1,430821
answered Nov 19 at 8:51
hendrik
1,430821
answered Nov 19 at 8:51
hendrik
1,430821
1,430821
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but ifgetMicrosecondPosition()was only returning correct values, if called from the same thread aswrite()or from within sync, I would expect this to be worth a note in the javadocs. Especially, aswrite()just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining themicrosecondPositionvalue. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation incom.sun.media.sound.DirectAudioDeviceis synchronized.
– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
add a comment |
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but ifgetMicrosecondPosition()was only returning correct values, if called from the same thread aswrite()or from within sync, I would expect this to be worth a note in the javadocs. Especially, aswrite()just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining themicrosecondPositionvalue. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation incom.sun.media.sound.DirectAudioDeviceis synchronized.
– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
That's not how I read and interpret the Javadocs. Assuming threadsafty in absence of a warning is IMO a huge fallacy.
– Markus Malkusch
Nov 23 at 15:02
I see your point, but if
getMicrosecondPosition() was only returning correct values, if called from the same thread as write() or from within sync, I would expect this to be worth a note in the javadocs. Especially, as write() just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining the microsecondPosition value. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation in com.sun.media.sound.DirectAudioDevice is synchronized.– hendrik
Nov 23 at 15:17
I see your point, but if
getMicrosecondPosition() was only returning correct values, if called from the same thread as write() or from within sync, I would expect this to be worth a note in the javadocs. Especially, as write() just places data into a buffer, which most likely is read by another thread that renders the audio. That thread is responsible for maintaining the microsecondPosition value. So we most likely have some interplay of threads anyway that should be properly synchronized. That all said, the implementation in com.sun.media.sound.DirectAudioDevice is synchronized.– hendrik
Nov 23 at 15:17
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
If you call List.add() and List.get() within two different threads, you might see cached values in the reader thread. That's the nature of Java's memory model and there's no need to emphasize this in the Javadoc of List. I assume the same for DataLine's documentation.
– Markus Malkusch
Nov 23 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
As I wrote: „I see your point“.
– hendrik
Nov 23 at 16:04
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53370948%2fis-dataline-getmicrosecondposition-thread-safe%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I don't know what you are trying to accomplish here, but for situations where I wish to coordinate playback with external events, I include messaging with the playback code. For example, a counter can count the number of frames sent for playback and when reaching certain milestones, can also sent a message (via loose coupling) to another thread.
– Phil Freihofner
Nov 22 at 18:41
Sure I could do that, but then OTOH I don't see the point in counting the sent frames if the API provides a method for that. Now I just need to know if I have to synchronize myself, or the API guarantees that I won't see a cached value on the reader's thread.
– Markus Malkusch
Nov 23 at 15:00
Basically, Java doesn't offer much in the way of real-time guarantees. I've found that counting frames is the best accuracy I've been able to get in for coordinating events on and off of the audio thread. A lot depends on what you are trying to do. I'm just trying to open the door to alternatives but am limited by the lack of big-picture info. If you wish to restrict yourself to a specific technical question, I'm not your guy. But I can say that in general using synchronization, which creates blocks, on the audio thread is to be avoided as it can easily lead to dropouts.
– Phil Freihofner
Nov 24 at 2:32
Some issues concerning low-latency audio are explained in this paper. javax.sound.sampled has been pretty stable the last decade, afaik. diuf.unifr.ch/main/pai/sites/diuf.unifr.ch.main.pai/files/…
– Phil Freihofner
Nov 24 at 2:39