View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002282 | ardour | bugs | public | 2008-06-07 17:45 | 2008-12-03 06:22 |
| Reporter | johne53 | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | SVN/2.0-ongoing | ||||
| Summary | 0002282: Timecode wrap-around problem at 96K sampling frequency | ||||
| Description | There seems to be a timecode wrap-around problem when working with high value timeline timecodes at any sampling rate higher than 48KHz. I discovered the problem at 96KHz but I suspect that it will happen at any sampling frequency higher than 48K. Create or open a 96KHz session. Set one of the big clocks to display 'Timecode'. Type in a timecode of exactly 11 hours. Notice that the time in the clock window is correct. Now click on the actual Timecode track. Note that instead of the edit cursor being reposition to approx 11 hours, it actually gets positioned to around 00:22:45:00 (this particular effect may be dependent on the value of the end marker because it also happens at lower sample rates). Now type exactly 13 hours into the clock. Notice that it reads the wrong timecode (usually around 00:34:20:00, but this can vary) 14 hours will give a reading of 01:34:20:00 etc etc. The timecode value must be getting truncated somewhere to a 32-bit integer, which doesn't have enough range to cope with sample rates higher than 48KHz. | ||||
| Additional Information | I discovered this in SVN3117 although I'll be upgrading to something newer this week and will check it again | ||||
| Tags | No tags attached. | ||||
|
|
i believe this should be fixed by my change about 3-4 weeks ago to make the Editor use 64 bit frame values everywhere. let me know if not. you can't represent times out to 24 hours with a 32 bit frame counter with SR>48kHz. |
|
|
Hi Paul. After an initial hiccup with Jack I managed to update to Jack svn 1100 which is apparently the latest version to be compatible with 64studio. It includes jack_get_time() which is the bit that I had problems with. I've now managed to build Ardour 2.4.1 (revision 3343 / svn 3461). However, the problem is still present. I suspect that the problem has more to do with the location markers than the timeline itself. For example, if you set an 'end' marker at 11 hours timecode, then grab it and try to move it forwards, it actually moves backwards. In fact, all location markers seem to "want" to have an upper limit of around 6 hours 13 minutes, so I suspect that they're still being implemented as signed 32-bit integers. [Edit: Ardour's svn number corrected] |
|
|
Your guess is correct. All that was changed was stuff in the GUI. The backend still defines nframes_t as an unsigned 32 bit integer (the same way that WAV does, alas). I do plan to change this, but it will require careful performance measurement on x86 systems to make sure that the hit is not too great. |
|
|
Confirmed to still be an issue on Ardour 2.7 Seablade |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-06-07 17:45 | johne53 | New Issue | |
| 2008-06-11 13:39 | paul | Note Added: 0005007 | |
| 2008-06-11 13:39 | paul | Status | new => feedback |
| 2008-06-14 06:15 | johne53 | Note Added: 0005022 | |
| 2008-06-14 17:22 | johne53 | Note Edited: 0005022 | |
| 2008-06-14 17:33 | paul | Note Added: 0005024 | |
| 2008-12-03 06:22 | seablade | Note Added: 0005462 | |
| 2008-12-03 06:22 | seablade | Status | feedback => confirmed |
