-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stream audio is silent #7
Comments
I don't think that is a problem. That should be handeld correctly. One thing I noticed looking at the Wireshark screenshot is, that the sequence number of the RTP packets are all the same for the 5 packets visible. They should normally be increasing. If every packet has the same sequence number (which would be a bug in the RTP implementation of the sender), I would guess that the buffering algorithm messes up, as it is based on the squence number. Try disabling RTP buffering in the settings and see if that works. |
I think that’s because those 5 packets are actually from 5 different streams. Only one of them is going to port 6518. I should have made the destination port column visible to show that. I’ll try disabling buffering. |
Some streams don't play any audio. I've added a stream from the following SDP. This particular stream works fine as a source in this tool: aes67-linux-daemon. I'm not sure what else I can tell you for troubleshooting, is there a log file? There is no indication of any error within the app. As soon as I click Listen the machine begins receiving RTP packets but I don't hear anything. Other sources of a similar format (L24/48000/8) work fine. Here's a Wireshark screenshot showing the packets being received. One unusual feature of this particular stream is that the source device sends multiple streams, each on a different UDP port, all using the same multicast destination address. Is that a problem here?
The text was updated successfully, but these errors were encountered: