Shine encoder for RPI

[stephen]

Reported by Brad G. via email:

On systems without an FPU (e.g. raspberry pi), nicercast using lame bindings can't cope with encoding audio on the fly. Could potentially switch to using shine enc, which performs much better on systems without an FPU (https://github.com/savonet/shine).

/usr/bin/sox -r 44.1k -e signed-integer -b 16 -c 2 -t raw - -t wavpcm - | shineenc - -

[RobertBiehl]

Is this really an issue with raspberry pi? I read that the raspberry pi has FPU and raspbian supports it.
I definitly have a performance problem. But I wonder if it's because of a lame encoder that has not been compiled with FPU support.

http://raspberrypi.stackexchange.com/questions/545/does-the-raspberry-pi-have-hardware-floating-point-support

[stephen]

Looks like you're on to something. Seems that the node library is compiled with the arm_nofpu optimization (thereby using soft floats..), but could use the fpu if compiled with generic_fpu. (see http://www.raspberrypi.org/forums/viewtopic.php?t=10656&p=150921).

See node-lame: https://github.com/TooTallNate/node-lame/blob/391ec00c8e25f2b86de338341184e8cd12abb5e8/deps/mpg123/mpg123.gyp#L60

Do you have experience with node-gyp? Could we add another target specifically for the rpi in node-lame?

Also see configure options:
https://github.com/TooTallNate/node-lame/blob/master/deps/mpg123/configure#L14046
https://github.com/TooTallNate/node-lame/blob/391ec00c8e25f2b86de338341184e8cd12abb5e8/deps/mpg123/mpg123.gyp#L108

[RobertBiehl]

No I didn't work with gyp yet. It should be possible to check for different arm versions there, like armv6 in the raspberry pi's case. The problem might be that some armv6 CPUs might miss an FPU unit. I could not find information on if that's possible. Maybe there is an architecture identifier like "armv6-vfp" to match against, which would make defining a target easier?

[stephen]

See TooTallNate/node-lame#30

[m1dst]

Have you considered NOT encoding the audio to MP3 at all? From what I understand the AirPlay codec is ALAC. The Sonos system can play ALAC 16/44.1 so perhaps this would be better for RPi to just pipe it straight out? I understand the bandwidth would be slightly more but it could create a stable platform for those not worried about the bandwidth. Perhaps I've missed something along the way so would be interested in your thoughts.

[stephen]

Closing for now. Currently looking into direct ALAC support (stephen/nodetunes#1).

Another workaround here is to overclock the rpi (stephen/airsonos#42).