Is DataLine.getMicrosecondPosition() thread-safe?
0
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 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
add a comment |
0
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 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
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 '18 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 '18 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 '18 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 '18 at 2:39
add a comment |
0
0
0
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 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
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 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
asked Nov 19 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
asked Nov 19 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
asked Nov 19 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
asked Nov 19 '18 at 8:38
Markus MalkuschMarkus Malkusch
5,4652151
5,4652151
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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 2:39
add a comment |
1 Answer
1
active
oldest
votes
0
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 '18 at 8:51
hendrikhendrik
1,517821
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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 at 16:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
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
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
0
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 '18 at 8:51
hendrikhendrik
1,517821
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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 at 16:04
add a comment |
0
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 '18 at 8:51
hendrikhendrik
1,517821
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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 at 16:04
add a comment |
0
0
0
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 '18 at 8:51
hendrikhendrik
1,517821
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 '18 at 8:51
hendrikhendrik
1,517821
answered Nov 19 '18 at 8:51
hendrikhendrik
1,517821
answered Nov 19 '18 at 8:51
hendrikhendrik
1,517821
answered Nov 19 '18 at 8:51
hendrikhendrik
1,517821
1,517821
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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 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 '18 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 '18 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 '18 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 '18 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 '18 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 '18 at 15:59
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 at 16:04
As I wrote: „I see your point“.
– hendrik
Nov 23 '18 at 16:04
add a comment |
draft saved
draft discarded
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.
draft saved
draft discarded
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 '18 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 '18 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 '18 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 '18 at 2:39