[IDEA] Streaming from Qobuz native app

[roderickvd]

Shouts out to another number of donations, thank you!

A short progress update:

   

Qobuz Connect works with a shared state between all connected devices ("renderers"). So each one has a copy of the playlist, current track position, etc. at each time. Then it states which renderer is the active one.

It seems I've got 99% of all incoming messages deciphered, so we can now follow the playback on another device. Autoplay and shuffle have some idiosyncrasies: we receive them OK, but I'm pretty sure it'll take a few iterations before we accurately copy the behavior from the official Qobuz apps.

This is a pretty big step, and I know move to the next phase: becoming the active renderer and actually playing some music!

[TheOldPresbyope]

@roderickvd

A long time ago in a galaxy far far away, I had to do a lot of protocol packet sniffing and analysis. It gave me a good appreciation of the challenges.

I tip my hat to you!

Regards,
Kent

[Nutul]

Hi-ha, same here, I've made cat and Wireshark sweat a lot, some 25/30 years ago. Great struggle, great fun.
Hat off here as well.

[roderickvd]

Short update: past weeks life has been happening, and in the fewer time I had left I have been working on Rodio, which I’m also a contributor to. pleezer and the upcoming Qobuz player depend on Rodio, which is a Rust audio processing and playback library. We’re working on getting a new version out of the door, which will be necessary for my players also.

So maybe nothing exciting, but important work under the hood.

[TheOldPresbyope]

Nice,

[Nutul]

Hi all, and hat off for your amazing work. Fomr a developer POV it's really understood.

From the same perspective, though, I'd like to ask... why using interpreted libraries to do some job on a machine that, say-what-you-want, has not horsepower, instead of using the mother-of-all-these-new-kiddo-languages, AKA "C"?

No pun intended; just curious. Java, C# (AKA Microsoft's Java, BTW) are powerful tools in their (niche) realm (that is: web interaction, mainly, where they excel (TM ???), especially C# from my own experience), let alone the various Ruby / Rust / LUA / Python (despite it is maybe the only great tool I can embrace ATM)... They drain CPU power at least double that's needed to a native C application.
Now, call me bigot, call me old-school, call me stereotyped... If there is one thing I have learned in my 40+ years career as a developer, is that there is a tool for everything, but not an everything-tool.

P.S.
It is evident that I am in love(and am devoted to, as well) with the C language... but in the end, once you master it... who isn't?

@TheOldPresbyope
Kent... this is most probably going to trigger some memories on your side. I am not meant to overload you, just in case... 

[roderickvd]

Rest assured: Rust is very much compiled, not interpreted.

[Nutul]

Rest assured: Rust is very much compiled, not interpreted.

In that case I may bow down. Just a bit, though... 
Let it not be just JIT-compiled.

[roderickvd]

Nope. Compiled all the way and statically linked. Rust’s speed and safety comes exactly because it offers so many compile-time guarantees. If you’re into C, I think you’re gonna love Rust.

[TheOldPresbyope]

This isn't the place for me to reminisce about the many languages I've dabbled in (or been forced to use) over the years. Since the first computer I got to use daily in my lab  (e.g., not handing punched card decks over the counter of our computer center) was a PDP-11/20 when it first came out, naturally I stand by DEC's Assembler and later MACRO-11.   The project couldn't afford a DEC-Tape drive so all the DEC software and my own programs had to be loaded from punched paper tape...again...and again...and again.  At least we had a "high speed" paper tape reader/ punch.
 
What I like most about Rust is its name. I'm reminded of it every morning when I get up and see my aging body in the mirror.

Regards,
Kent