9 Nov
2016
9 Nov
'16
9:04 p.m.
>>
Warning. 4GB limit on wav file almost reached.
and the .wav file stops at 4GB.
So it does seem to be a problem with the 32-bit version of jack_capture. 
10 Nov
10 Nov
6:29 a.m.
New subject: everything stops after 2.1GB
Kjetil Matheussen wrote:
I don't think so. Jeanette had the same problem
when using jack_rec,
and I can't think of any reason why jack_capture should behave
differently when running on a 32 bit OS. It's far more likely to be
caused by the filesystem, or something else. I've cc-ed
Erik de Castro Lopo, the author of libsndfile. He probably
knows more about what could cause max file sizes of 2.1GB.
I didn't manage to get to the bottom of which piece of software
was causing the problem.
From the POV of libsndfile, it has had Large File
Support (which
makes file offsets 64 bit signed values) on 32 bit systems for over
a decade.
However, it is possible for other software using libsndfile incorrectly
(ie using a 32 bit integer to store file offsets) to cause this sort
of a problem, but then I would expect it to go wrong on 64 bit systems
because `int` is 32 bits there too. However on 32 bit Linux systems,
`long` whereas it us 64 bits on 64 bit Linux systems.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
8:23 a.m.
New subject: everything stops after 2.1GB
Hey hey,
after having tested with Ecasound and still gotten 2.1GB, I suspect the
package build of libsndfile for Arch and will write a mail to the Arch
mailinglist. Ecasound can write larger files, as tested with raw output. So
raw output is an alternative for the time being, but it would require
something like Ecasound to play it back, since only there a file format can be
specified.
Warmly yours and thanks for all the help,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
9:09 a.m.
New subject: everything stops after 2.1GB
On Thu, 10 Nov 2016 09:23:44 +0100 (CET), J. C. wrote:
I suspect the package build of libsndfile for Arch
Then you should take a look at the PKGBUILD. I already posted by my
previous mail.
Consider to read https://wiki.archlinux.org/index.php/Arch_Build_System
and just send such a request to arch general, if you already checked a
PKGBUILD yourself, but you still have questions.
If you found a culprit, then report the bug,
https://wiki.archlinux.org/index.php/Reporting_bug_guidelines and don't
send an email to the mailing list.
Regards,
Ralf
8:37 p.m.
New subject: everything stops after 2.1GB
On Thu, November 10, 2016 2:23 am, J. C. wrote:
raw output is an alternative for the time being, but
it would require
something like Ecasound to play it back, since only there a file format
can be specified.
The SoX program can of course convert nearly any format to nearly an other
format.
The -r option must be given to describe the sample rate of the raw file,
-e for signed, unsigned, float encoding format of samples, -b for size of
samples in number of bits, -c for number of channels in raw file. If no
changes are desired, just a header, then the last argument is the file
name with format extension.
I do not have a raw file to test this, but I think for a 48 k sample rate,
32 bit float as used by jack, 2 channel raw file the conversion would be:
sox -r 48k -e floating-point -b 32 -c 2 long_night.raw long_night.w64
Maybe ecasound does not use floating point, perhaps you configure 16 bit
output to save space. This should convert:
sox -r 48k -e signed-integer -b 16 -c 2 long_night.raw long_night.w64
--
Chris Caudle
8:56 p.m.
New subject: everything stops after 2.1GB
Hi Chris,
Nov 10 2016, Chris Caudle has written:
On Thu, November 10, 2016 2:23 am, J. C. wrote:
I was aware of that, but the question is, if SoX will suffer from the
same limitation, since it too is linked to libsndfile. But I can give it
a try.
Thanks for the commandline examples, if unused to SoX, it can take a
while to find the right options.
...
--------
When you need someone, you just turn around and I will be there <3
raw output is an alternative for the time being,
but it would require
something like Ecasound to play it back, since only there a file format
can be specified.
The SoX program can of course convert nearly any format to nearly an other
format.
11:58 p.m.
New subject: everything stops after 2.1GB
On Thu, 10 Nov 2016 21:56:47 +0100 (CET), J. C. wrote:
I was aware of that, but the question is, if SoX will
suffer from the
same limitation, since it too is linked to libsndfile.
Since Kjetil guess seems to be plausible, I would try adding
"-D_FILE_OFFSET_BITS=64"
to the flags in makepkg.conf. I don't know, if it belongs there, but
since it doesn't take much time to test it, I wouldn't wait for a
reply, how to handle this and simply test it.
12 Nov
12 Nov
10:27 p.m.
New subject: everything stops after 2.1GB
Ralf Mardorf wrote:
Since Kjetil guess seems to be plausible, I would try
adding
"-D_FILE_OFFSET_BITS=64"
to the flags in makepkg.conf. I don't know, if it belongs there, but
since it doesn't take much time to test it, I wouldn't wait for a
reply, how to handle this and simply test it.
That may not help, because to get libsndfile to built on a 32 bit
system *without* large file support, I'm pretty sure they would have
had to patch the libsndfile sources.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
10:54 p.m.
New subject: everything stops after 2.1GB
On Sun, 13 Nov 2016 09:27:47 +1100, Erik de Castro Lopo wrote:
Ralf Mardorf wrote:
"Pretty sure"?
As already pointed out, the Arch package does use the source from
upstream. It is not patched.
The only changes are:
sed -i 's|#!/usr/bin/python|#!/usr/bin/python2|' src/binheader_writef_check.py
\
src/create_symbols_file.py programs/test-sndfile-metadata-set.py
sed -i 's|python|&2|' src/Makefile.am
And it's configured with:
./configure --prefix=/usr --disable-sqlite
See:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packa…
The default flags - not necessarily used by the package maintainer -
are:
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="@CARCH@"
CHOST="@CHOST@"
#-- Compiler and Linker Flags
# -march (or -mcpu) builds exclusively for an architecture
# -mtune optimizes for an architecture, but builds for whole processor family
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="@CARCHFLAGS@ -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="@CARCHFLAGS@ -mtune=generic -O2 -pipe -fstack-protector-strong"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
#-- Make Flags: change this for DistCC/SMP systems
#MAKEFLAGS="-j2"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
See:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/makepkg.conf?h=p…
Regards,
Ralf
Since Kjetil guess seems to be plausible, I would
try adding
"-D_FILE_OFFSET_BITS=64"
to the flags in makepkg.conf. I don't know, if it belongs there, but
since it doesn't take much time to test it, I wouldn't wait for a
reply, how to handle this and simply test it.
That may not help, because to get libsndfile to built on a 32 bit
system *without* large file support, I'm pretty sure they would have
had to patch the libsndfile sources.
13 Nov
13 Nov
8:48 a.m.
New subject: everything stops after 2.1GB
Ralf Mardorf wrote:
"Pretty sure"?
As already pointed out, the Arch package does use the source from
upstream. It is not patched.
So I looked that the sources, and there *was* code that would fail
at runtime of Large File Support was not enabled. This was removed
because at one stage (not even sure if this is still the case)
Android (32 bit) did not have Large File Support.
Large File Support gets enabled by default on 32 Debian.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
9:39 a.m.
New subject: everything stops after 2.1GB
On Sun, 13 Nov 2016 19:48:30 +1100, Erik de Castro Lopo wrote:
Ralf Mardorf wrote:
So it's done by a default build flag? If so the OP could add the flag
to the Arch default build flags or to the PKGBUILD, too and rebuild the
package.
For an Arch user the Debian rules file is cryptic.
"DEB_BUILD_MAINT_OPTIONS = hardening=+all
CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS)
LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
config.status: configure
dh_testdir
dh_autoreconf
$(shell dpkg-buildflags --export=configure) ./configure \
--disable-silent-rules \
--host=$(DEB_HOST_GNU_TYPE)
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info" -
https://tracker.debian.org/media/packages/libs/libsndfile/rules-1.0.27-1
"Pretty sure"?
As already pointed out, the Arch package does use the source from
upstream. It is not patched.
So I looked that the sources, and there *was* code that would fail
at runtime of Large File Support was not enabled. This was removed
because at one stage (not even sure if this is still the case)
Android (32 bit) did not have Large File Support.
Large File Support gets enabled by default on 32 Debian.
14 Nov
14 Nov
7:48 a.m.
New subject: everything stops after 2.1GB
Ralf Mardorf wrote:
Turns out LFS got broken some time in 2013 and noone noticed until now.
The fix is here:
https://github.com/erikd/libsndfile/commit/e4572180c3445ce1afdc9e36ab8c2163…
There was test for this added to the test suite in the commit before
that one.
Guess I should release a new version soon.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Large File
Support gets enabled by default on 32 Debian.
So it's done by a default build flag? If so the OP could add the flag
to the Arch default build flags or to the PKGBUILD, too and rebuild the
package. 
9:51 a.m.
New subject: everything stops after 2.1GB
Sorry Erik. I'd have reported this but I didn't think it was actually a bug
or issue with libsndfile at all.
On Mon, Nov 14, 2016 at 7:48 AM, Erik de Castro Lopo <mle+la(a)mega-nerd.com>
wrote:
Ralf Mardorf wrote:
Turns out LFS got broken some time in 2013 and noone noticed until now.
The fix is here:
https://github.com/erikd/libsndfile/commit/
e4572180c3445ce1afdc9e36ab8c2163637e0755
There was test for this added to the test suite in the commit before
that one.
Guess I should release a new version soon.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Large File
Support gets enabled by default on 32 Debian.
So it's done by a default build flag? If so the OP could add the flag
to the Arch default build flags or to the PKGBUILD, too and rebuild the
package.
11:52 a.m.
New subject: everything stops after 2.1GB
On Mon, 14 Nov 2016 18:48:31 +1100, Erik de Castro Lopo wrote:
Ralf Mardorf wrote:
Turns out LFS got broken some time in 2013 and noone noticed until now.
The fix is here:
https://github.com/erikd/libsndfile/commit/e4572180c3445ce1afdc9e36ab8c2163…
There was test for this added to the test suite in the commit before
that one.
Guess I should release a new version soon.
:)
I guess it doesn't happen that often that somebody needs audio
files > 2 GiB, let alone that the user at the same time needs to be on
32bit architecture, while e.g. Ubuntu flavours will drop 32bit support
soon.
Regards,
Ralf
Large File
Support gets enabled by default on 32 Debian.
So it's done by a default build flag? If so the OP could add the flag
to the Arch default build flags or to the PKGBUILD, too and rebuild
the package.
2752
days inactive
2757
days old
linux-audio-user@lists.linuxaudio.org
13 comments
6 participants
participants (6)
-
Chris Caudle -
Erik de Castro Lopo -
J. C. -
Kjetil Matheussen -
Paul Davis -
Ralf Mardorf