python-soundfile icon indicating copy to clipboard operation
python-soundfile copied to clipboard

Published 20 hours ago • verified publisher icon bastibe

test_read_int_data_from_float_file fails on armhf

Open itdaniher opened this issue 8 years ago • 6 comments

Python 3.6.0 (default, Dec 31 2016, 21:20:16) [GCC 4.9.2] on linux

Linux debian 3.4.113-sun8i #50 SMP PREEMPT Mon Nov 14 08:41:55 CET 2016 armv7l GNU/Linux

libsndfile1-dev / libsndfile1 from stretch, v 1.0.27-1

PySoundFile @ eff15c03174c496421ea65a587bd8529bcb56181

results of

python setup.py test | curl -F 'sprunge=<-' http://sprunge.us

at http://sprunge.us/NFHZ

itdaniher avatar Jan 29 '17 17:01 itdaniher

Could you re-run this with -v so we can see the full diff? At any rate though, this kind of error is probably an issue within libsndfile, since the Python code does not change between platforms, but libsndfile does.

bastibe avatar Jan 30 '17 08:01 bastibe

The test fails on all 32bit platforms...

The two variables it compares are two lists and the first value is different: returned [ 32767, -32768, -32767, -1, -1, 0, 0, 0, 1, 1, 32766, 32767, 32767] expected (-32768, -32768, -32767, -1, -1, 0, 0, 0, 1, 1, 32766, 32767, 32767)

scarabeusiv avatar Aug 17 '18 09:08 scarabeusiv

It seems that expected should be a numpy array, but is a tuple. Do you want to create a pull request that fixes this?

bastibe avatar Sep 03 '18 10:09 bastibe

The problem is not array vs Tuple, but the first value differs: The returned is 32767 while it wanted -32768

scarabeusiv avatar Sep 03 '18 10:09 scarabeusiv

@bastibe The equality operator (==) for NumPy arrays works with "array-like" objects. Using a tuple works fine.

The problem seems to be that libsndfile behaves differently on 32bit and 64bit platforms.

Value in FLOAT file: -2.0**15 - 1, a.k.a. -32769.0.

Expected value when reading it as PCM_16: -2**15 a.k.a. -32768. Note that this value is (correctly) clipped to the range of PCM_16.

Observed value on 32bit systems: 2**15 - 1 a.k.a. 32767. This looks like the value was (incorrectly) wrapped around to the maximum positive value instead of being clipped.

This looks very much like a bug in libsndfile, probably @erikd can confirm this?

If this turns out to be a bug in libsndfile, the unit test in question should probably be marked as "expected fail" on 32-bit systems?

mgeier avatar Sep 03 '18 10:09 mgeier

I don't currently have access to any 32 bit systems, Arm or otherwise.

Some who does should build libsndfile from source and run the test suite.

erikd avatar Sep 04 '18 20:09 erikd