Playback not starting on `next` branch with either HttpRequest or YoutubeDL on M series ARM SoCs

Question

Playback not starting on `next` branch with either HttpRequest or YoutubeDL on M series ARM SoCs

maxall41 opened this issue 2 years ago · 12 comments

Songbird version: next branch

Rust version (rustc -V): 1.69.0

Serenity/Twilight version: next

Description:
I'm trying to play a track with HttpRequest and it doesn't seem to be playing I was also able to recreate this using the voice example on the next branch. I don't get any errors or anything it just doesn't play.
...

Steps to reproduce:

Copy serenity/voice example from the next branch
Attempt to play youtube video using bot

Answer 1 · 2023-05-09T07:22:57.000Z

It sounds like you're trying to play a track from youtube using an HttpRequest. You need to use YoutubeDl (and ensure you have yt-dlp installed) -- HttpRequest lets you download from an URL which points directly to an audio source (e.g., "https://test.com/song.mp3"), but youtube effectively requires that you use a tool like yt-dlp to retrieve the URL of the audio/video data from a CDN,

Answer 2 · 2023-05-09T16:54:27.000Z

Sorry I wasn't clear is what i meant was I am trying to download a youtube video with YoutubeDL and it's not working and i am also having the same problem downloading and streaming standard files with HttpRequest in that in both cases I get no errors and I get event that says they started playback but playback does not occur.

Answer 3 · 2023-05-09T23:18:59.000Z

I found the issue. Rubato does not seem to work on MacOS with apple silicon I was able to get it working by running it in a linux VM on AWS. This should probably be noted in the documentation.

Answer 4 · 2023-05-10T07:06:46.000Z

Ouch, that's unfortunate. Perhaps you could raise an issue with the Rubato devs? From what I can see they claim SIMD support on AArch64 as a feature, so it's not as if the library is x86_64 only by design.

Answer 5 · 2023-05-10T07:20:47.000Z

Yeah I’ll create an issue over there.

Answer 6 · 2023-05-14T19:31:43.000Z

Rubato works fine on macOS on both intel and arm.

Answer 7 · 2023-05-14T19:35:38.000Z

This issue seems to be due to an implementation issue in songbird. See issue HEnquist/rubato#59

Answer 8 · 2023-05-14T21:09:34.000Z

Interesting; unfortunately, I don't have a personal mac to test with. My best guess is format conversions biting somewhere between songbird and symphonia, unless there's some weird interaction with the chunk sizes we use?

Answer 9 · 2023-05-19T00:34:38.000Z

I might be able to look into this when i have some more time.

Answer 10 · 2023-05-19T03:58:10.000Z

Update: I tried to recreate this on an AWS Graviton instance and I was not able to recreate it. So this seems to be some sort of obscure issue with the M series SoC specific architecture. And not an issue with ARM architecture in general. Or maybe it's some sort of obscure bug in the darwin kernel

Answer 11 · 2023-05-24T01:07:07.000Z

yeah- i have this issue too, with raw audio sources

Answer 12 · 2023-08-29T09:42:06.000Z

@maxall41 Sorry to necropost, but after #193 was raised I've had the opportunity to test on an M-series Mac and I'm able to playback and resample MP3 sources via HttpRequest in a call. The issue there was that Darwin errors out when setting the UDP receive buffer length to zero -- let me know if you still have any issues.