9 Nov
2016
9 Nov
'16
9:45 a.m.
Hey hey again,
sorry to be back so soon. But both jack_rec and jack_capture with formats
ranging from wav, w64 to caf, break off after 2.1GB filesize. Since all of
these are uncompressed and the other variables stay the same, this equals six
hours, twelve minutes and 49 seconds.
My jack_capture commandline currently looks like this:
jack_capture -as -f caf -b 16 -c 1 -p system:capture_1 $FILENAME
I get no complaints, JACK is still running and the system is fine. I'm using
jack_capture 0.9.71 from Arch AUR.
Can anyone think of the issue in question or a solution or tests to approach
the problem?
Thanks and best wishes,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
9 Nov
9 Nov
9:56 a.m.
Did you already read the follow-ups? It already was clear that the limit
is not caused by the wav formats.
Any chance you increased your tmpfs from 1,7G to around 2.1G in the
meantime and you perhaps by mistake was recording in a tmpfs directory?
Regards,
Ralf
10:09 a.m.
Am 09.11.2016 um 09:45 schrieb J. C.:
Can anyone think of the issue in question or a
solution or tests to
approach the problem?
To which filesystem are you saving the recording? Is it perhaps a (V)FAT
partition? Or a very old ext2 filesystem? Some of these have limitations
on maximum file size.
Chris
10:24 a.m.
On Wed, 9 Nov 2016 10:09:45 +0100, Christopher Arndt wrote:
Am 09.11.2016 um 09:45 schrieb J. C.:
How old should this ext2 be? Let alone that Arch is a rolling release
and if you buy e.g. an USB stick, it unlikely is formatted with ext.
In regards to the file system, I only could imagine tmpfs being the
culprit.
"Max. file size 16 GiB – 2 TiB" -
https://en.wikipedia.org/wiki/Ext2
"On Linux kernels prior to 2.6.17,[4] restrictions in the block driver
mean that ext2 filesystems have a maximum file size of 2 TiB." -
https://en.wikipedia.org/wiki/Ext2
"Max. file size 4,294,967,295 bytes (4 GiB – 1) with FAT16B and
FAT32[1]" - https://en.wikipedia.org/wiki/File_Allocation_Table
"Max. file size ca. 128 PiB (theoretical 16 EiB–1)[nb 1]" -
https://en.wikipedia.org/wiki/ExFAT
"Further, the term "VFAT" has led to various misconceptions as well,[nb
1] as it is sometimes erroneously used as if it would describe another
variant of FAT file system to be distinguished from the FAT12, FAT16
and FAT32 file systems, while in reality it does not specify another
file system" - https://en.wikipedia.org/wiki/File_Allocation_Table
Regards,
Ralf
Can anyone think of the issue in question or a
solution or tests to
approach the problem?
To which filesystem are you saving the recording? Is it perhaps a
(V)FAT partition? Or a very old ext2 filesystem? Some of these have
limitations on maximum file size.
11:24 a.m.
Hi Chris,
Nov 9 2016, Christopher Arndt has written:
...
To which filesystem are you saving the recording?
I'm saving everything to an ext3 filesystem with about 220GB of free
space.
...
Best wishes,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
11:33 a.m.
arecord has options that are related to 2GB limits. Consider to test
arecord for recordings > 2GB.
http://manpages.ubuntu.com/manpages/xenial/man1/aplay.1.html
Regards,
Ralf
12:10 p.m.
On 11/09/2016 10:25 AM, J. C. wrote:
Hi Chris,
Nov 9 2016, Christopher Arndt has written:
...
may i ask what's the output of:
ulimit -a
or more specifically:
ulimit -f
?
--
rncbc aka. Rui Nuno Capela
To which filesystem are you saving the recording?
I'm saving everything to an ext3 filesystem with about 220GB of free
space.
...
12:56 p.m.
Den 2016-11-09 kl. 11:25, skrev J. C.:
Hi Chris,
Nov 9 2016, Christopher Arndt has written:
...
Once upon time we did like this to test filesystem with large files.
dd if=/dev/zero of=3GB_file bs=1024 count=3M
--
/bengan
To which filesystem are you saving the recording?
I'm saving everything to an ext3 filesystem with about 220GB of free
space.
1:03 p.m.
Hi Bengan,
Nov 9 2016, Bengt Gördén has written:
Once upon time we did like this to test filesystem
with large files.
dd if=/dev/zero of=3GB_file bs=1024 count=3M
Eventhough, I seem to re all
downloading bigger files, I executed the
above command with the expected result of a 3.1GB file. So the system is
sane in that respect.
Thanks for giving it a shot. It is appreciated, as has been with every
suggestion made by all the other posters.
TTFN,
Jeanette
...
--------
When you need someone, you just turn around and I will be there <3
7:56 p.m.
On 11/09/2016 09:45 AM, J. C. wrote:
Hey hey again,
sorry to be back so soon. But both jack_rec and jack_capture with
formats ranging from wav, w64 to caf, break off after 2.1GB filesize.
Since all of these are uncompressed and the other variables stay the
same, this equals six hours, twelve minutes and 49 seconds.
My jack_capture commandline currently looks like this:
jack_capture -as -f caf -b 16 -c 1 -p system:capture_1 $FILENAME
I get no complaints, JACK is still running and the system is fine. I'm
using jack_capture 0.9.71 from Arch AUR.
Can anyone think of the issue in question or a solution or tests to
approach the problem?
Thanks and best wishes,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Are you perhaps on a 32bit OS?
8:08 p.m.
Nov 9 2016, Markus Seeber has written:
...
Are you perhaps on a 32bit OS?
Yes, I am, but
would that really effect the systems facility to read and
interpret 64bit integers in a file? After all, I thought 64bit
architectures are only necessary if you want to use more than 4GB of RAM
mainly and of course a few more optimisations on the CPU level when it
comes to working with 64BIT ints. I know that Csound can use 64bit
integers on a 32BIT platform. Was I really that wrong about it?
Best wishes,
Jeanette
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--------
When you need someone, you just turn around and I will be there <3
8:18 p.m.
OT:
On Wed, 9 Nov 2016 20:08:39 +0100 (CET), J. C. wrote:
Was I really that wrong about it?
In regards to 32bit packages, some software might be compiled for
hardware compatibility e.g. without SSE2. From time to time there are
discussions about what features should be used for official packages,
for 32bit and for 64bit architecture.Usually 32bit architecture should
be compatible to very old machines, so it could come with a lot of
limitations.
32bit kernels usually have PAE enabled, so the 3.75GiB limit or what
ever else it was, is irrelevant in regards to RAM.
Regarding the topic, I'm curious too, especially since 32bit wav
anyway should allow files up to 4 GiB.
8:47 p.m.
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
Nov 9 2016, Markus Seeber has written:
...
No, but it could be a bug/misfeature in the software you are using for
recording. It could be related to an integer overflow when using a
32-bit signed integer to keep track of file size or something similar.
In C, an 'int' would compile to a 32-bit or 64-bit variable according to
the word size of the target machine. As other possible causes don't
seem to apply, this seems likely.
Can you try the recording with the same command line options on a
64-bit OS, and with a 64-bit version of the same recording software?
Are you perhaps on a 32bit OS?
Yes, I
am, but would that really effect the systems facility to read and
interpret 64bit integers in a file?
9:11 p.m.
FYI, I tried jack_capture on a 64-Bit OS and used jack_freewheel so I
didn't have to wait for hours for hitting the 2.1 GB "mark".
jack_capture will output
>> 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.
This should be fixed, but in the meantime, I can recommend
jack_timemachine for recording. jack_rec might also work.
Best,
J.
On Wed, 9 Nov 2016 20:47:26 +0100
Johannes Kroll <j-kroll(a)gmx.de> wrote:
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
[...]
[...]
[...]
No, but it could be a bug/misfeature in the software you are using for
recording. It could be related to an integer overflow when using a
32-bit signed integer to keep track of file size or something similar.
In C, an 'int' would compile to a 32-bit or 64-bit variable according to
the word size of the target machine. As other possible causes don't
seem to apply, this seems likely.
Can you try the recording with the same command line options on a
64-bit OS, and with a 64-bit version of the same recording software?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:15 p.m.
Nov 9 2016, Johannes Kroll has written:
...
So it does seem to be a problem with the 32-bit
version of jack_capture.
This should be fixed, but in the meantime, I can recommend
jack_timemachine for recording. jack_rec might also work.
...
Thanks Johannes. I didn't get timemachine to compile and jack_rec had
the same issue. But I'm trying ecasound with w64. Otherwise I might
compile one of those apps myself and see if it makes a change.
Warm regards,
Jeanette
--------
When you need someone, you just turn around and I will be there <3
10:41 p.m.
On Wed, 9 Nov 2016 21:15:19 +0100 (CET), J. C. wrote:
Nov 9 2016, Johannes Kroll has written:
...
Did you use the PKGBUILD I posted? If so, paste the output of makepkg,
if not, try using the PKGBUILD.
;)
--
Nach den Wahlen erklären Statistiken, warum die Statistiken vor den
Wahlen falsch waren.
So it does seem to be a problem with the 32-bit
version of
jack_capture. This should be fixed, but in the meantime, I can
recommend jack_timemachine for recording. jack_rec might also work.
...
Thanks Johannes. I didn't get timemachine to compile
10:44 p.m.
Nov 9 2016, Ralf Mardorf has written:
...
Did you use the PKGBUILD I posted? If so, paste the
output of makepkg,
if not, try using the PKGBUILD.
Not yet Ralf. But thanks, I'll keep it in mind.
For now, I'll give
Ecasound a got. After all, it has severed me very well for years. :) I'd
just thought that something more streamlined and simpler might do. :)
Best wishes,
Jeanette
;)
--
Nach den Wahlen erklären Statistiken, warum die Statistiken vor den
Wahlen falsch waren.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--------
When you need someone, you just turn around and I will be there <3
10 Nov
10 Nov
12:25 a.m.
On 11/09/2016 04:41 PM, Ralf Mardorf wrote:
On Wed, 9 Nov 2016 21:15:19 +0100 (CET), J. C. wrote:
I just did. build/installs quickly. Thanks Ralf!
[tweed@Arch-Twr6 PkgBld]$ makepkg -s PKGBUILD
[tweed@Arch-Twr6 PkgBld]$ sudo pacman -U
timemachine-0.3.3-3-x86_64.pkg.tar.xz
[tweed@Arch-Twr6 PkgBld]$ timemachine
Attempting to auto-start LASH server
Not sending deprecated LASH_Client_Name event
opened 'tm-2016-11-09T18:16:04.w64'
writing buffer...
writing realtime data...
done writing...
^C
[tweed@Arch-Twr6 PkgBld]$
--
www.the-temp-agency.com/lollipop-factory
Nov 9 2016, Johannes Kroll has written:
...
Did you use the PKGBUILD
I posted? If so, paste the output of makepkg,
if not, try using the PKGBUILD.
;)
So it does seem to be a problem with the 32-bit
version of
jack_capture. This should be fixed, but in the meantime, I can
recommend jack_timemachine for recording. jack_rec might also work.
...
Thanks Johannes. I didn't get timemachine to compile
9 Nov
9 Nov
10:49 p.m.
On Wed, 9 Nov 2016 21:15:19 +0100 (CET), J. C. wrote:
Nov 9 2016, Johannes Kroll has written:
...
> jack_timemachine
My apologies,
"timemachine" does not contain something named "jack_timemachine".
[rocketmouse@archlinux ~]$ pacman -Ql timemachine
timemachine /usr/
timemachine /usr/bin/
timemachine /usr/bin/timemachine
timemachine /usr/share/
timemachine /usr/share/timemachine/
timemachine /usr/share/timemachine/pixmaps/
timemachine /usr/share/timemachine/pixmaps/busy.png
timemachine /usr/share/timemachine/pixmaps/off-icon.png
timemachine /usr/share/timemachine/pixmaps/off.png
timemachine /usr/share/timemachine/pixmaps/on-icon.png
timemachine /usr/share/timemachine/pixmaps/on.png
timemachine /usr/share/timemachine/pixmaps/timemachine-icon.png
[rocketmouse@archlinux ~]$
10 Nov
10 Nov
11:59 a.m.
On 09/11/16 19:47, Johannes Kroll wrote:
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
Sorry, that's not true. In earlier times,
before things like standards were
invented and 32 bits seemed a lot, int=16 bits, long=32bits. When they got
round to standardising C, int was defined as either 16 or 32 bits, depending
on the architecture. Short=16 bits, long=32bits. Then 64 bits came in, and
16-bit machine were virtually forgotten. int was then only vaguely defined
but in practice it is always 32 bits (unless you have a very old
compiler for
a 16-bit machine). It does NOT extend to 64 bits, with the possible
exception
of some obscure machines that only support 64 bits (CDC?). Long is either
32 or 64 bit, depending on applicable architecture.
The only reliable way is to use the extended types: int_16, int_32, int_64
which are now available (for those that like typing longer names.... ;-))
Bill
--
+----------------------------------------+
| Bill Purvis |
| email: bill(a)billp.org |
+----------------------------------------+
Nov 9 2016, Markus Seeber has written:
...
No, but it could be a bug/misfeature in the
software you are using for
recording. It could be related to an integer overflow when using a
32-bit signed integer to keep track of file size or something similar.
In C, an 'int' would compile to a 32-bit or 64-bit variable according to
the word size of the target machine. As other possible causes don't
seem to apply, this seems likely. Are you perhaps on a 32bit OS?
Yes, I am,
but would that really effect the systems facility to read and
interpret 64bit integers in a file?
12:43 p.m.
On Thu, 10 Nov 2016 10:59:31 +0000, Bill Purvis wrote:
On 09/11/16 19:47, Johannes Kroll wrote:
Perhaps useful information for those who program, but irrelevant for
this thread, since WAV files > 2GiB don't require 64bit at all.
libsndfile on Arch, this is what the OP does use, is configured with
"--prefix=/usr --disable-sqlite" and it's the latest official upstream
release without patches and no changes excepted of
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
I hope we agree on the following:
1. wav, even 32bit is not limited to 2GiB
2. ext3, with ulimit file size unlimited on a partition where > 100GiB
are free, allows to write files >2GiB
Regards,
Ralf
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
Sorry, that's not true. In
earlier times, before things like standards
were invented and 32 bits seemed a lot, int=16 bits, long=32bits. When
they got round to standardising C, int was defined as either 16 or 32
bits, depending on the architecture. Short=16 bits, long=32bits. Then
64 bits came in, and 16-bit machine were virtually forgotten. int was
then only vaguely defined but in practice it is always 32 bits (unless
you have a very old compiler for
a 16-bit machine). It does NOT extend to 64 bits, with the possible
exception
of some obscure machines that only support 64 bits (CDC?). Long is
either 32 or 64 bit, depending on applicable architecture.
The only reliable way is to use the extended types: int_16, int_32,
int_64 which are now available (for those that like typing longer
names.... ;-)) Nov 9 2016, Markus Seeber has written:
...
No, but it could be a
bug/misfeature in the software you are using
for recording. It could be related to an integer overflow when using
a 32-bit signed integer to keep track of file size or something
similar. In C, an 'int' would compile to a 32-bit or 64-bit variable
according to the word size of the target machine. As other possible
causes don't seem to apply, this seems likely. Are you perhaps on a 32bit OS?
Yes, I
am, but would that really effect the systems facility to
read and interpret 64bit integers in a file?
2:44 p.m.
On Thu, 10 Nov 2016 10:59:31 +0000
Bill Purvis <bill(a)billp.org> wrote:
On 09/11/16 19:47, Johannes Kroll wrote:
You're right of course. Replace "int" with "long" in my message
above
and it starts to make sense.
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
Sorry, that's not true. In earlier times,
before things like standards were
invented and 32 bits seemed a lot, int=16 bits, long=32bits. When they got
round to standardising C, int was defined as either 16 or 32 bits, depending
on the architecture. Short=16 bits, long=32bits. Then 64 bits came in, and
16-bit machine were virtually forgotten. int was then only vaguely defined
but in practice it is always 32 bits (unless you have a very old
compiler for
a 16-bit machine). It does NOT extend to 64 bits, with the possible
exception
of some obscure machines that only support 64 bits (CDC?). Long is either
32 or 64 bit, depending on applicable architecture. Nov 9 2016, Markus Seeber has written:
...
No, but it could be a bug/misfeature in the
software you are using for
recording. It could be related to an integer overflow when using a
32-bit signed integer to keep track of file size or something similar.
In C, an 'int' would compile to a 32-bit or 64-bit variable according to
the word size of the target machine. As other possible causes don't
seem to apply, this seems likely. Are you perhaps on a 32bit OS?
Yes, I
am, but would that really effect the systems facility to read and
interpret 64bit integers in a file? The only reliable way is to use the extended types:
int_16, int_32, int_64
which are now available (for those that like typing longer names.... ;-))
(u)int32_t etc, yes.
9 Nov
9 Nov
8:10 p.m.
On Wed, 9 Nov 2016 19:52:20 +0100, Markus Seeber wrote:
Are you perhaps on a 32bit OS?
On Arch general she mentioned using i683, but even if Jeanette should
use 64bit architecture, please inform the list about pitfalls on
32bit architecture, if you are aware of them. Becoming aware of
limitations could help each subscriber, to avoid running into trouble,
at the most inconvenient time.
TIA,
Ralf
2936
days inactive
2937
days old
linux-audio-user@lists.linuxaudio.org
23 comments
9 participants
participants (9)
-
Bengt Gördén -
Bill Purvis -
Christopher Arndt -
J. C. -
Johannes Kroll -
Markus Seeber -
Ralf Mardorf -
Rui Nuno Capela -
Tweed