Feedback on svn-1417 and ideas for ticket 191

[xaviour]

Hi,

I am using firefly svn-1417 on a deunderclocked NSLU2 connecting to a Pinnacle Soundbridge M1000. My entire music collection is about 4900 songs ripped from CD to ogg vorbis format. I chose firefly against Slimserver because of the memory consumption. Slimserver used about 80% of the NSLU2 available memory and made it swap all the time, even we not doing anything useful. Firefly on the other hand stays below 25% memory usage and does not make the device swap. So Firefly is already very useful to me.

I am also an audioscrobbler user which makes that I am interested in having a way to upload my list of played tracks either in real time (by the Soundbridge or by Firefly) or once per week using Portable Player Logging. Currently none of both strategies work with transcoded tracks.

So I had a look at the source. I have been able to increment the playcount of the transcoded tracks (in “_plugin_ssc_transcode”). This works only if the track has not be skipped or stopped. So for playcount to work properly with transcoded tracks, it is necessary to have a way to know whether the track was played fully (Portable Player Logging does not require played tracks to be updated at 50%).

As far as I understand it from a private email with Ron and looking at the source, transcoding works by transcoding the file to wav and streaming it as fast as possible. I assume that the Soundbridge takes care of the buffering and flow control. If Firefly is installed on a modern PC and sends a small track, it is perfectly possible to have Firefly sends the full transcoded track before having the user hitting the skip button of its remote. As a consequence, the logging will be very unreliable. On an embedded device on the other hand, the transcoding is done almost in real time (oggdec uses about 80% of the CPU). So this strategy is probably reliable enough for embedded devices.

Firefly plugin function “_plugin_ssc_transcode” returns the number of bytes of the transcoded stream. This is not very useful because VBR files have an average throughput in bits/second for the compressed stream. It does not tell us anything about the size of the uncompressed stream (the one we transmit).

Another angle is to postpone updating the playcount until a new request for a track comes. If the new request comes before the playtime of the track currently being played is elapsed, it means that the track has been skipped. Could someone from Roku tell me if the Soundbridge requests the next track before the current one has finished playing? Even in this case, it could be possible to mark a track as played if the track has been played for more than 50% of its duration (that’s what audioscrobbler uses for live updates if I am not mistaken).

Yet another angle is to detect if the Soundbridge stops requesting the track (closes the HTTP connection?) before the transcoding process is finished. If do wonder what happens if the user pauses the track. Here is another question for the people of Roku. Does the Soundbridge close the HTTP connection if a track is paused? Ron, do you know what happen if the user skips a track? Does it mean that the Soundbridge close the HTTP connection and that “ws_writebinary” will fail at line 538 of “plugin.c”?

[rpedde]

@xaviour wrote:

On an embedded device on the other hand, the transcoding is done almost in real time (oggdec uses about 80% of the CPU). So this strategy is probably reliable enough for embedded devices.

That’s interesting. Are you not using the ivorbis-tools package? The integer decoder should be much faster than that… I regularly do ogg transcoding on an underclocked slug using the integer decoder. The point is a good one, though — on a slow machine it may not prebuffer much.

Another angle is to postpone updating the playcount until a new request for a track comes. If the new request comes before the playtime of the track currently being played is elapsed, it means that the track has been skipped. Could someone from Roku tell me if the Soundbridge requests the next track before the current one has finished playing? Even in this case, it could be possible to mark a track as played if the track has been played for more than 50% of its duration (that’s what audioscrobbler uses for live updates if I am not mistaken).

That seems reasonable, but I don’t really keep any kind of session state. I try not to, anyway. So it would be hard to determine whose request was the next request. Particularly when there is more than one user updating it.

Yet another angle is to detect if the Soundbridge stops requesting the track (closes the HTTP connection?) before the transcoding process is finished. If do wonder what happens if the user pauses the track.

That’s what it tries to do right now, by using the served bytes length. I still think this might be both the easiest, and most close to accurate method to use.

Here is another question for the people of Roku. Does the Soundbridge close the HTTP connection if a track is paused? Ron, do you know what happen if the user skips a track? Does it mean that the Soundbridge close the HTTP connection and that “ws_writebinary” will fail at line 538 of “plugin.c”?

The soundbridge does close the connection on a pause, then seeks to the proper position on a play.

If a user skips a track, the soundbridge closes the connection and opens a new one. ws_writebinary fails, and the transcode function returns a bytecount smaller than the bytecount expected.

— Ron

[xaviour]

@rpedde wrote:

That’s interesting. Are you not using the ivorbis-tools package? The integer decoder should be much faster than that… I regularly do ogg transcoding on an underclocked slug using the integer decoder. The point is a good one, though — on a slow machine it may not prebuffer much.

Now that I think about it, I am indeed using ivorbis-tools and not tremor. I was a bit in a rush and did not take the time to look for speed optimization in my setup (OpenSLUG 3.10 + some local compilation).

@rpedde wrote:

That seems reasonable, but I don’t really keep any kind of session state. I try not to, anyway. So it would be hard to figure out whose request was the next request. Particularly when there is more than one user updating it.

I think you are right to keep it simple. I am just looking at options. I prefer Firefly small, efficient and reliable.

Anyhow, I am going to have a look at the RCP (Roku Control Protocol) specification and figure out if it is powerful enough to monitor the track played. I think a small daemon (or a helper program spawned by Firefly) running on the NSLU2 and asking the status of the Soundbridge every second could do the trick.

This would not work for non Soundbridge players but:
– most software players have their own audioscrobbler plugin.
– other hardware devices vendors are always welcome to satisfy their customers by either integrating the audioscrobbler functionality or providing a remote control protocol like Roku is doing.

[fizze]

Yeah, I ahve thought of something like that too.
My first thought was to query the mt-daapds homepage with the info for a certain host periodically, but when I found out it uses javascript to do just that, that idea died fast 😉

A daemon to fetch the info would be cool. 🙂

[rpedde]

@fizze wrote:

Yeah, I ahve thought of something like that too.
My first thought was to query the mt-daapds homepage with the info for a certain host periodically, but when I found out it uses javascript to do just that, that idea died fast 😉

A daemon to fetch the info would be cool. 🙂

All the stuff that’s on the web page gets fetched by the javascript in xml. It would be easier to pull the raw xml and parse it then try and screen-scrap the stuff of the web page anyway.

[fizze]

yarre! 🙂

thanks for the heads-up, I’ll try.
dang, there is no try. I’ll do it, then. 😛

[xaviour]

@xaviour wrote:

Anyhow, I am going to have a look at the RCP (Roku Control Protocol) specification and figure out if it is powerful enough to monitor the track played. I think a small daemon (or a helper program spawned by Firefly) running on the NSLU2 and asking the status of the Soundbridge every second could do the trick.

So I did a little bit of experimenting. The NSLU2 streams some music to the soundbridge and I monitor it from my linux PC:

telnet soundbridge 5555

Trying 192.168.1.69...

Connected to soundbridge.

Escape character is '^]'.

roku: ready

GetCurrentSongInfo

GetCurrentSongInfo: id: 4965

GetCurrentSongInfo: trackLengthMS: 295891

GetCurrentSongInfo: year: 2006

GetCurrentSongInfo: discNumber: 1

GetCurrentSongInfo: discCount: 1

GetCurrentSongInfo: trackNumber: 4

GetCurrentSongInfo: trackCount: 20

GetCurrentSongInfo: format: AAC

GetCurrentSongInfo: status: playable

GetCurrentSongInfo: title: Listen to Your Heart (Swedish Single Edit)

GetCurrentSongInfo: artist: Roxette

GetCurrentSongInfo: album: A Collection of Roxette Hits - Their 20 Greatest Songs

GetCurrentSongInfo: genre: Pop

GetCurrentSongInfo: songFormat: mp4a

GetCurrentSongInfo: formatDescription: AAC audio file

GetCurrentSongInfo: resource[0] url: http://192.168.1.67:3689/rsp/stream/4965

GetCurrentSongInfo: resource[0] format: AAC

GetCurrentSongInfo: resource[0] bitrate: 200

GetCurrentSongInfo: resource[0] sampleRate: 44100

GetCurrentSongInfo: resource[0] sizeBytes: 4832254

GetCurrentSongInfo: OK

GetElapsedTime

GetElapsedTime: 0:00:12

GetElapsedTime

GetElapsedTime: 0:00:14

exit

Connection closed by foreign host.

It is important to note that between the moment you start telnet and the moment you get the prompt more than 10 seconds elapse. This means that the TCP connection should stay open during the monitoring.

[Author]

Posts