Streaming to Sony NAS-SV20i fails #7
Comments
|
Debug output |
|
Try building from https://github.com/ugjka/blast/tree/7-streaming-to-sony-nas-sv20i-fails branch Or try this build |
|
The problem seems it doesn't like this part in the code // handle devices like Samsung TVs
if r.Header.Get("GetContentFeatures.DLNA.ORG") == "1" {
f := dlnaContentFeatures{
profileName: "MP3",
supportTimeSeek: false,
supportRange: false,
flags: DLNA_ORG_FLAG_STREAMING_TRANSFER_MODE | DLNA_ORG_FLAG_DLNA_V15,
}
w.Header().Set("ContentFeatures.DLNA.ORG", f.String())
}In the test build I zeroed out the flags, if that doesn't work then I'll try disabling the content features header completely, or maybe i need to send MPEG instead of MP3 |
|
Seemingly same issue |
|
I updated the branch with content features disabled Build: |
|
Extracted to a new folder to make sure I wasnt reusing an old copy. Same messages. |
|
Ok, lets not exit blast when play error is thrown, perhaps it can still play afterwards Build: |
|
Looks like the idea of the player being slow to load doesn't hold up. Never starts playing anything. I know this definitely supports MP3 as I can browse from the speakers to another UPnP server and load files fine. As well as sending to the speakers from BubbleUPnP. BubbleUPnP's audio cast on Android sends PCM and does work with the same Sony set, if that's of any use info wise. |
|
It reads the http headers by making a head request and then bails out, it doesn't like what it gets, so here is a build that only sends content-type header |
|
I have high hopes that it doesn't like content-length header bigger than 32 bit value, but will see |
|
No luck there either. I attempted a wireshark capture but I'm not seeing the data I expect (For one the Sony doesnt even have any packets talking to the computer) |
|
Well, where is this HEAD request coming from? |
|
I meant the Sony IS talking to the computer, just that my wireshark capture is faulty and I can't figure out why. |
|
Ok, lets switch it up and send wav audio instead Build: |
|
Receiver is still choking on something. I get the little blinking icons on the display indicating that it tried to start loading but lord knows what's failing. |
|
I'm going to sleep and think about it tomorrow or some other day, but it looks like it expects some header particularly something about Getcontentfeatures.dlna.org. I have some dlna spec docs and need to check out some other implementations. Perhaps i'll get bubbleupnp app and try to sniff it to see what is it doing |
|
Here's a pcapng of the Sony MAC |
|
Thanks a ton for the help! Get some rest. |
|
Forgot to get the other half of the conversation (Sony as dst) |
|
I think i found a clue https://stackoverflow.com/questions/46856189/upnp-control-point-cannot-playing-audio wee need to set some metadata, gonna work on it |
|
you can try https://github.com/ugjka/blast/releases and see if it fixes the problem |
|
Promising! The unit makes a few attempts to play it and throws an error code, so it may be down to MP3 formatting. |
|
|
|
I've prepared a build with multiple test cases: blast.zip There are 5 test cases, starting with 1 You can run them like this ./blast -test 1 Test 1: do not send "Content-Length" header |
|
Also try the latest version i pushed which handles CTE https://github.com/ugjka/blast/releases/tag/v0.5.0 |
|
All the tests are coming back the same. The streaming is "working" now with the same 81004 error. I believe it doesn't like the formatting of the MP3 stream. Maybe a build with the new fixes and WAV/PCM? 0.5.0Same 81004 |
|
can you try sending some internet mp3 radio streams to your device with this: dlna-send.zip like: I'll try maing wav version when i have time |
|
sanity check when running blast can you open the stream url in your browser or some other player or even cast to other dlna device like bubbleupnp when running blast is there blast-rec device active in linux audio settings |
|
Heres the full pcap for Bubble |
|
Oh I dont think this is the radio. Playing the stream back on the phone is just as garbled. Is this possibly feeding MP3 data into a WAV container erroneously? |
|
Oh your lpcm is advertising at s16be but it's actually s32le. Manually specificying the format to ffplay loads correctly and sounds correct I tried |
|
So another rabbit hole I just went down was grabbing the line input via the network as this supports it. ffplay was giving me a weird 406 but curl directly worked. Which leads me to an interesting discovery. This unit sends out S32BE. So that may be the preferred format overall. |
|
Same mismatch... Just garbled audio |
|
My point was piping that curl into ffplay I HAD to use |
|
What happens if you actually specify the sample rate and channels, like this :
can you also post edit: also |
|
perhaps i need to add --raw to parec command parecCMD := exec.Command(
"parec",
"--device="+s.sink,
"--client-name=blast-rec",
"--rate="+fmt.Sprint(s.samplerate),
"--channels="+fmt.Sprint(s.channels),
"--format="+fmt.Sprintf("s%dle", s.bitdepth),
"--raw",
)or for some reason the new build: [edit: check the last post] also what is your linux system's endianess |
|
Can you check your mic audio with this, which is basically what blast does
you should be able to hear your own voice if the mic is working |
|
new build: blast.zip has |
Testing from the phone which has been the same results as from the Steam Deck Screen_Recording_20240217_111905_Termux.mp4It'll be a second before I can test with the computer again. |
Yeah this works fine. The weirdness I was seeing was streams from the Sony device (not related to this issue was just trying to see what formats the device liked). About to try the log version |
|
FFMpeg seems to be in order. The Sony device is NOT playing (or serving for that matter) s16le properly (which is what got me checking the streaming FROM rabbit hole) The Sony speakers themselves are a 2010 embedded Linux device. There's a good chance they themselves are big endian native. So in short, Formats from the Steam Deck https://gist.github.com/parkerlreed/ce628a05741cac76b5b82a682a93558a Parec https://gist.github.com/parkerlreed/21d9c01bf4ac7005a64d312caa88fa99 |
|
I will write a flag that let's you swap endianess |
|
Trying decoding with s16BE doesn't work for some reason. Screen_Recording_20240217_114746_Termux.mp4 |
|
Would you like a raw dump of the stream to mess with? That might be easier (To see what format it is ACTUALLY compatible with) |
|
new build: blast.zip try |
|
Okay, interesting discovery. If you dump it to a file first, FFmpeg is happy. So it does appear to actually be S16BE. I went to test the dump I made straight to a file and it played correctly. |
|
yeah i guess your device is big endian and bubbleupnp somehow can detect it |
|
Success! I can't express how thankful I am. You are awesome. |
|
Thank you for patience 😹 this was a wild ride and i learned a lot! I'll merge the changes and push a new release and later when i have time I'll work on a way to detect endianess of remote devices automatically, perhaps i need to pay closer look to pcaps you sent |
Oh you love to see it. ffmpeg stopped passing in the extra arguments after mine type because it fixed HLS streams. Not considering that things actually use that for like rate and channels. https://trac.ffmpeg.org/ticket/10869 That's why it was broken for streaming, but playing for the local file. |
|
Apparently you can use this method to pass byte order as well |
The Sony receiver takes about 10 seconds to start a stream. blast errors out almost instantaneously (the display on the Sony shows that it tries to start loading it)
The text was updated successfully, but these errors were encountered: