View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000543 | ardour | bugs | public | 2004-06-17 00:08 | 2008-11-20 23:46 |
| Reporter | baver | Assigned To | paul | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000543: bad write errors occur when .wav file size reaches 2.0 GB | ||||
| Description | After recording for 1.5 hours with 4 tracks, I receive the following errors for each track that is recording in ardour: Log and the recording stops: [ERROR]: FileSource: "/usr/local/baver/Media/Audio/RecordTest//sounds//Guitars-2.wav" bad write (Interrupted system call) [ERROR]: DiskStream 1085705852559480: cannot write to disk [ERROR]: Butler write-behind failure on dstream Guitars When I checked the size of the files, I found that the files that have been written are 2147483647 bytes (the number also being the upper bounds of a signed 32-bit integer) at the time the recording stops. | ||||
| Additional Information | Problem exists back in beta11.2 as well as libardour 0.816.0 and Ardour/GTK 0.516.0. | ||||
| Tags | No tags attached. | ||||
|
|
Yes, we've discussed this problem in the past. There is no simple way around it. 1) WAV files are limited to 32 bit data "chunk" size 2) JACK can only reference 2^32 frames Without moving to WAV-64, we can't solve it. However, what we can do is provide a better warning and/or automatically switch over to a new source so that capture continues uninterrupted. Thoughts? |
|
|
Automatically switching over to a new source makes sense to me (maybe a note in the log when it happens so that the user knows what has happened). Thanks! |
|
|
This bug was caused by the default limits on filesizes in Linux/POSIX. The CVS codebase now uses "Large File Support", so that all native ardour audio files can be extended to 4GB. The theoretical limit is much higher (about 8TB), but because jack_nframes_t, the basic type used to specify a frame position, is only 32 bits, 4GB is the current practical limit. Ardour should probably have some warning show up when recording a single pass that starts to approach this limit. |
|
|
Reopened by the request of gmaxwell |
|
|
I'm seeing this issue with Ardour/GTK 0.9beta29 (built using 0.589.2 with libardour 0.887.1), from CCRMA on a fresh FC3 install on ia32. I have no issues making >2gb files on the underlying filesystem (in fact almost everything these days seems to work with them). After bombing out at 1.5hrs of 96k recording with the write errors like above I was able to cleanly save my session.. But ardour would not reopen the audio segments that had hit maximum size: ERROR]: FileSource: cannot seek to end of file [ERROR]: FileSource: cannot locate chunks in /home/audio/data/test/sounds/Audio 1-1%L.wav [ERROR]: SndFileSource: cannot open file "Audio 1-1%L.wav" (System error.) [ERROR]: Found a sound file that cannot be used by Ardour. See the progammers. [ERROR]: Session: cannot create Source from XML description. [ERROR]: FileSource: cannot seek to end of file [ERROR]: FileSource: cannot locate chunks in /home/audio/data/test/sounds/Audio 1-1%R.wav [ERROR]: SndFileSource: cannot open file "Audio 1-1%R.wav" (System error.) ... I'm guessing that the large file support is broken someplace, so that should be fixed. Also, if we're still stuck with a 32 bit limit on ia32 then we should do something a little more graceful at that limit, for example, stopping recording on our own at just under 4gb so the files will open. .. 3 hours of continous recording wouldn't be unusual, think musical theater, but 6 would be fine probably, so we could fix this by removing the regression, making the handling a little more graceful, and puting a notice in the docs so users needing >3 hrs of recordings know to split it up or run at 48k. If we need a good seekable container for PCM in the future to get us beyond 4g, we could (ab)use OGG. |
|
|
We now support WAV64, as well as CAF. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-06-17 00:08 | baver | New Issue | |
| 2004-06-17 00:08 | baver | => baver@thebeever.com | |
| 2004-06-17 00:08 | baver | Name | => Richard Baverstock |
| 2004-06-17 01:27 | paul | Note Added: 0001055 | |
| 2004-06-17 01:27 | paul | Priority | urgent => normal |
| 2004-06-17 01:27 | paul | Status | new => acknowledged |
| 2004-06-17 03:01 | baver | Note Added: 0001059 | |
| 2004-06-19 14:02 | paul | Status | acknowledged => resolved |
| 2004-06-19 14:02 | paul | Resolution | open => fixed |
| 2004-06-19 14:02 | paul | Assigned To | => paul |
| 2004-06-19 14:02 | paul | Note Added: 0001072 | |
| 2005-06-11 21:19 | v2 | baver@thebeever.com => | |
| 2005-06-11 21:19 | v2 | Name | Richard Baverstock => |
| 2005-06-11 21:19 | v2 | Status | resolved => feedback |
| 2005-06-11 21:19 | v2 | Resolution | fixed => reopened |
| 2005-06-11 21:19 | v2 | Note Added: 0002265 | |
| 2005-06-11 21:30 | gmaxwell | Note Added: 0002266 | |
| 2006-11-06 19:36 | taybin | Status | feedback => resolved |
| 2006-11-06 19:36 | taybin | Resolution | reopened => fixed |
| 2006-11-06 19:36 | taybin | Note Added: 0002687 | |
| 2008-11-20 23:46 | seablade | Status | resolved => closed |
