(moved from another thread)
From initial analysis the unit uses Gstreamer (RTSP?) to stream audio. It runs Linux with 3.x kernel on an ARMV7L-compatible hardware.
The Spark application starts up some proprietary udp signaling service on port 24242, then Gstreamer service (on port 4040, the standard RTSP port) and populates a database (sqlite-based) with the data available for playback.
Playback is initiated via some custom-looking protocol, providing the unit the url of the gstreamer stream to play, smth like "http://<hashed address>.dvlt:4040/<song hash><hashed address repeated> if deciphered correctly.
The unit then issues an http call to the Gstreamer service being run by Spark app on port 4040, doing "HTTP GET" on the url above (the part after the .dvlt:4040)
User agent is shown as Gstreamer soulhttpsrc libsoup/2.43.1
From a short analysis of the unit itself, it seems to be running some 3.x version of Linux kernel.
So there are several parts that are very strange here.
First, there is no GPL-related information on devialet website, possibly because there is nothing customized in the Linux system it is running. Still, they could possibly be required to provide at least the GPL text with it. IANAL though, especially in French law.
Second, if the unit understands standard Gstreamer streams, why not provide ability for customers to use standard Gstreamer services for use with the unit?
In any case, on the port 24242 side, the unit is constantly broadcasting beacon messages with plaintext magic bytes
"DVL.WHO?" and "DVL.HERE <serial num>".
When Spark app sees a beacon, it initiates a connection to the unit invoking some custom command with arguments:
"com.devialet.whatsup.registry.<12hex chars>" and
"com.devialet.callmemaybe.connect.<32 hex chars>"
It then continues with second packet sending:
"com.devialet.getthepartystarted.log-uploader-0.<8hex chars>"
then url of where to send log (probably):
"tcp://127.0.0.1:<some port number>"
and
"com.devialet.source-0.online-0.authenticated-0.pickupthepieces.<8hex chars>
and same "tcp://..." string
At some point the unit sends a packet to Spark, with generic structure of: "<command>.<address> <serial_num> tcp://127.0.0.1:<some_port>".
Ports are generally different, serial number is the Unit's serial number, and address differs from 8 hex chars (4bytes) to 12 hex chars (6bytes) to 32 hex chars (16 bytes).
These are possibly to map different service sources/sinks to different ports, and the rest of communication is on those ports.
As shown above, packets coming from Spark have commands of
com.devialet.whatsup.registry
com.devialet.callmemaybe.connect
com.devialet.getthepartystarted.log-uploader-0
com.devialet.source-0.online-0.authenticated-0.pickupthepieces
Commands seen from the unit sent to Spark:
com.devialet.imaslave4u.configuration-0,
com.devialet.imaslave4u.soundcontrol-0
com.devialet.canttouchthis.hid-0.button-0.capacitive-0
com.devialet.canttouchthis.hid-0.button-0.power-switch-0
com.devialet.canttouchthis.hid-0.host-remote-0.blue-0
com.devialet.playthatfunkymusic.configuration-0
com.devialet.playthatfunkymusic.playback-0
com.devialet.source-configure-0.bluetooth-0.blue-0
com.devialet.source-0.live-0.bluetooth-0.blue-0
com.devialet.source-0.live-0.optical-0
com.devialet.source-0.online-0.authenticated-0.pickupthepieces (unpause command?)
com.devialet.source-session-0.online-0.pickupthepieces (unpause command?)
com.devialet.tiktok.clock-0
com.devialet.toomanyflows.soundcontrol-0
com.devialet.toomanyflows.playlist-0
com.devialet.toomanyflows.playback-0
com.devialet.toomanyflows.history-0
com.devialet.toomanyflows.configuration-0
com.devialet.twerkit.sounddesign-0.toomanyflows-0
com.devialet.twerkit.sounddesign-0.imaslave4u-0
com.devialet.masterofpuppets.configuration-0
com.devialet.getthepartystarted.configuration-0
Playlist synchronization and playback control is done over the playlist port via the gstreamer-rtsp-like urls.
The sqlite db is in "collection.db" file which is in the user's local app data (/Users/<username>/AppData/Devialet/Spark on win, and probably somewhere in ~/Library/Application Support/ on mac).
By the way, in Mac OS X El Capitan, the Phantom works very well thru aptx (352Kbit/sec *lossless) at 44/16, as the bluetooth chip in the Phantom is made by CSR, the inventors/buyers/owners of Aptx.
MacOS doesn't seem to allow rates other than 44KHz though.
Spark makes some requests to store.dvlt.io (managed by bearstech.com), probably some kind of firmware update check.
Would be superb if someone with well-configured and working system of 2+ Phantoms would help see the work on the masterofpuppets port.
There are as it seems 10 ports in use: debug, log, "masterofpuppets", buttons, optical, "getthepartystarted", slave-control, playlist, "playthatfunkymusic", bluetooth.
From initial analysis the unit uses Gstreamer (RTSP?) to stream audio. It runs Linux with 3.x kernel on an ARMV7L-compatible hardware.
The Spark application starts up some proprietary udp signaling service on port 24242, then Gstreamer service (on port 4040, the standard RTSP port) and populates a database (sqlite-based) with the data available for playback.
Playback is initiated via some custom-looking protocol, providing the unit the url of the gstreamer stream to play, smth like "http://<hashed address>.dvlt:4040/<song hash><hashed address repeated> if deciphered correctly.
The unit then issues an http call to the Gstreamer service being run by Spark app on port 4040, doing "HTTP GET" on the url above (the part after the .dvlt:4040)
User agent is shown as Gstreamer soulhttpsrc libsoup/2.43.1
From a short analysis of the unit itself, it seems to be running some 3.x version of Linux kernel.
So there are several parts that are very strange here.
First, there is no GPL-related information on devialet website, possibly because there is nothing customized in the Linux system it is running. Still, they could possibly be required to provide at least the GPL text with it. IANAL though, especially in French law.
Second, if the unit understands standard Gstreamer streams, why not provide ability for customers to use standard Gstreamer services for use with the unit?
In any case, on the port 24242 side, the unit is constantly broadcasting beacon messages with plaintext magic bytes
"DVL.WHO?" and "DVL.HERE <serial num>".
When Spark app sees a beacon, it initiates a connection to the unit invoking some custom command with arguments:
"com.devialet.whatsup.registry.<12hex chars>" and
"com.devialet.callmemaybe.connect.<32 hex chars>"
It then continues with second packet sending:
"com.devialet.getthepartystarted.log-uploader-0.<8hex chars>"
then url of where to send log (probably):
"tcp://127.0.0.1:<some port number>"
and
"com.devialet.source-0.online-0.authenticated-0.pickupthepieces.<8hex chars>
and same "tcp://..." string
At some point the unit sends a packet to Spark, with generic structure of: "<command>.<address> <serial_num> tcp://127.0.0.1:<some_port>".
Ports are generally different, serial number is the Unit's serial number, and address differs from 8 hex chars (4bytes) to 12 hex chars (6bytes) to 32 hex chars (16 bytes).
These are possibly to map different service sources/sinks to different ports, and the rest of communication is on those ports.
As shown above, packets coming from Spark have commands of
com.devialet.whatsup.registry
com.devialet.callmemaybe.connect
com.devialet.getthepartystarted.log-uploader-0
com.devialet.source-0.online-0.authenticated-0.pickupthepieces
Commands seen from the unit sent to Spark:
com.devialet.imaslave4u.configuration-0,
com.devialet.imaslave4u.soundcontrol-0
com.devialet.canttouchthis.hid-0.button-0.capacitive-0
com.devialet.canttouchthis.hid-0.button-0.power-switch-0
com.devialet.canttouchthis.hid-0.host-remote-0.blue-0
com.devialet.playthatfunkymusic.configuration-0
com.devialet.playthatfunkymusic.playback-0
com.devialet.source-configure-0.bluetooth-0.blue-0
com.devialet.source-0.live-0.bluetooth-0.blue-0
com.devialet.source-0.live-0.optical-0
com.devialet.source-0.online-0.authenticated-0.pickupthepieces (unpause command?)
com.devialet.source-session-0.online-0.pickupthepieces (unpause command?)
com.devialet.tiktok.clock-0
com.devialet.toomanyflows.soundcontrol-0
com.devialet.toomanyflows.playlist-0
com.devialet.toomanyflows.playback-0
com.devialet.toomanyflows.history-0
com.devialet.toomanyflows.configuration-0
com.devialet.twerkit.sounddesign-0.toomanyflows-0
com.devialet.twerkit.sounddesign-0.imaslave4u-0
com.devialet.masterofpuppets.configuration-0
com.devialet.getthepartystarted.configuration-0
Playlist synchronization and playback control is done over the playlist port via the gstreamer-rtsp-like urls.
The sqlite db is in "collection.db" file which is in the user's local app data (/Users/<username>/AppData/Devialet/Spark on win, and probably somewhere in ~/Library/Application Support/ on mac).
By the way, in Mac OS X El Capitan, the Phantom works very well thru aptx (352Kbit/sec *lossless) at 44/16, as the bluetooth chip in the Phantom is made by CSR, the inventors/buyers/owners of Aptx.
MacOS doesn't seem to allow rates other than 44KHz though.
Spark makes some requests to store.dvlt.io (managed by bearstech.com), probably some kind of firmware update check.
Would be superb if someone with well-configured and working system of 2+ Phantoms would help see the work on the masterofpuppets port.
There are as it seems 10 ports in use: debug, log, "masterofpuppets", buttons, optical, "getthepartystarted", slave-control, playlist, "playthatfunkymusic", bluetooth.
