RTP rom x64 to ARM does not work

[Chili]

Hello!

I'm trying to send an rtp stream from a pc with x64 processor to a device having an ARMv5 CPU.

When the stream is on the cpuload on the ARM device rises to 40% and pulseaudio slowly eats up all memory.

On the receiver side (ARM) pacmd reports: sample spec: s16be 2ch 39690Hz for rtp-recv, but this should be 44100Hz

Between x64 and x86 machines the stream works fine.

Pulseaudion version: 2.6.22 (from source on x64, x86, from debian experimental on ARM)

Any ideas?

Best regards!

[mkbosmans]

Do you have a running audio stream, i.e. can you hear the audio on the other end?

FWIW, high CPU load is expected on underpowered processors. You can try setting the resampling algorithm to a less complex one.

Please test with lastest git master, as the problem relating to the wildly deviating sample rate should be adressed there.

[rozzin]

I had a `doesn't work' issue which I suspect is the same as Chili's, and I've determined the cause well enough to get it working: I'm using module-rtp-send on an x86-32 host, and module-rtp-recv on an ARM host--and I'd verified the RTP multicast was working with both x86-64 and x86-32 receivers, and I could see from the output of "pulseaudio -vvv" that the RTP stream was being received by module-rtp-recv on the ARM host, I just wasn't hearing any audio output.

The ARM receiver is an Ionics Nimbus 100 (which is a Sheeva Plug work-alike--using the same Marvell kirkwood platform) with a USB audio-adaptor. The USB audio-adaptor was verified to work with PulseAudio on my x86-64 laptop, even in an RTP-receiver setup--and the USB adaptor even worked *with the ARM host* when playing 44.1-kHz audio-files through PulseAudio.

The ARM and x86-32 hosts both have the same word-sizes and are of the same endianness, so neither of those was the problem. The only notable difference between all of my x86 desktops/laptops and my ARM plug-computer is that all of the x86 machines have floating-point units, and the ARM machine doesn't--and that's the problem: without an FPU, the default resampling-method (speex-float) doesn't work; the latency on the plug-computer seems to be more variable than on any of my x86 receivers, so the input-stream is rarely running at exactly 44100 samples/sec and resampling is almost always necessary.

So I edited /etc/pulse/daemon.conf, changing resample-method from speex-float-3 to speex-fixed-3, and now everything appears to be working just fine.

This may still be considered a bug, though: if the floating-point resamplers don't work, it might be a good idea to just fall back to a fixed-point resampler automatically.