Skip to content
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

Open
llamafilm opened this issue Jan 20, 2022 · 3 comments
Open

Stream audio is silent #7

llamafilm opened this issue Jan 20, 2022 · 3 comments

Comments

@llamafilm
Copy link

llamafilm commented Jan 20, 2022

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?

v=0
o=- 100 0 IN IP4 10.49.51.51
s=CP950 1-8
c=IN IP4 239.69.83.67/32
t=0 0
a=clock-domain:PTPv2 0
m=audio 6518 RTP/AVP 96
a=rtpmap:96 L24/48000/8
a=ptime:1
a=mediaclk:direct=0
a=ts-refclk:ptp=IEEE1588-2008:00-60-DB-FF-FE-01-02-CA:0
a=recvonly

Screen Shot 2022-01-19 at 21 31 16

@philhartung
Copy link
Owner

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.

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.

@llamafilm
Copy link
Author

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.

@llamafilm
Copy link
Author

Thanks for the tip, but disabling RTP buffering did not make any difference. Here in this new screenshot you can see the sequence numbers are incrementing by 1 each time (port 6518 in this case)
Screen Shot 2022-01-20 at 10 43 12

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants