thcilnnahoj.
em32sn003We are having problems recording long sessions with podium. It seems to
slow down after about 15 minutes of recording with occasional buffer overflows. We are recording the raw 32 channels. Do you know of a solution? Has anyone else seen the problem?
ZynewaveHi,
Which Podium version?
32 channels into one .wav file?
What bit-resolution is the .wav file set to?
Are there any other soundfiles playing/recording simultaneously?
What does the Podium CPU indicator Mix/File percentages read before the problem starts occurring?
How do you detect the problem, i.e. is it the Podium CPU File indicator that starts blinking red?
Is the buffer overflow only a problem with the monitoring, or is it also detectable in the recorded .wav file?
pj geerlingsJust a random thought here really but ..
32 * 15 * 60 * 44100 * 4 > 4Gigs
32 tracks
15 minutes
60 seconds/minute
44100 samples/second
4 Bytes / sample
em32sn003@Zynewave wrote:
Hi,
Which Podium version?
32 channels into one .wav file?
What bit-resolution is the .wav file set to?
Are there any other soundfiles playing/recording simultaneously?
What does the Podium CPU indicator Mix/File percentages read before the problem starts occurring?
How do you detect the problem, i.e. is it the Podium CPU File indicator that starts blinking red?
Is the buffer overflow only a problem with the monitoring, or is it also detectable in the recorded .wav file?
Podium version: 2.09
We do eventually save to a single .wav file – yes
16 bits/sample
No other simultaneous recordings/playback
Podium CPU file indicator starts blinking red, graphics (cursor) stalls.
So far, we have not detected any artifacts in the actual recordings.
ZynewaveI apologize for this late reply. I was deep into some code changes that I wanted to finish first.
Today I tested recording multi-channel files for longer periods. I managed to record a 32-channel 32-bit sound for over an hour. The saved .wav file was at +20GB. I noticed that the Podium CPU usage increased as the recording progressed. When I had passed one hour recording the UI had become very sluggish. That may be the same symptoms you experienced after 15 minutes. It will depend on the system specs of the machine.
How much memory do you have installed?
I’m going to work on improving the performance of long recordings in one of the next releases. Thanks for bringing this issue to my attention.
em32sn003@Zynewave wrote:
I apologize for this late reply. I was deep into some code changes that I wanted to finish first.
Today I tested recording multi-channel files for longer periods. I managed to record a 32-channel 32-bit sound for over an hour. The saved .wav file was at +20GB. I noticed that the Podium CPU usage increased as the recording progressed. When I had passed one hour recording the UI had become very sluggish. That may be the same symptoms you experienced after 15 minutes. It will depend on the system specs of the machine.
How much memory do you have installed?
I’m going to work on improving the performance of long recordings in one of the next releases. Thanks for bringing this issue to my attention.
Thanks for looking at the issue.
It would also be good if the data was somehow recoverable – after a crash. I imagine the data is being written to some temporary file space? Currently all data is lost after a crash. You can probably understand the frustration of recording a one-off concert and losing it entirely due to a crash after an hour of recording.
Zynewave@em32sn003 wrote:
It would also be good if the data was somehow recoverable – after a crash. I imagine the data is being written to some temporary file space? Currently all data is lost after a crash. You can probably understand the frustration of recording a one-off concert and losing it entirely due to a crash after an hour of recording.
Yes, all recorded/edited sample data is written to temporary cache files, and only committed to sound files once you save all changes to the project. I’m considering different solutions for recording directly to the sound files. This will make it possible to do a recovery of recorded audio should the project crash before it has been saved.
em32sn003We are using a laptop (a MacBook Pro) running Windows XP, with 2 GB of RAM. The Processor is a Intel Core2Duo T8300 @ 2.40GHz.
The disk drive is about 160GB with 120GB free space at the moment.
angelofarinaFirst of all, any WAV files cannot exceed 2Gbytes, as it has a 32-bits header.
For long files, WAVE64 should be used. W64 files can be of any length…
For recording long 32-channels, 32-bits files with our Eigenmike (SN005), we usually employ Plogue Bidule, which can save a single W64 file containing all the 32 channels…
Bidule also natively supports the 32ins-8out EM32 VST plugin, for creating the virtual microphones…..
Another important fact is that Plogue Bidule also runs natively under MAC OSX, no need to boot the Macbook with Window$. The TCAT DICE II drivers are also available for MAC-OSX… And, of course, the Mac native HFS file system manages large W64 files much better than Windows’ NTFS filesystem…
I’m sorry to have to report here that a shareware program is beating Podium for this task, but this is a fact, and I find this can be useful to know for all users of Eigenmike microphones….
druidHalf of that read like an advertisement for Macintosh, actually.
thcilnnahojWhile I share neither the animosity towards Windows nor Mac OS :wink:, I just want to add that Podium supports 32-channel RF64 files fine, too.
However, since you’re on Mac OS anyway, have you thought about using CAF instead, with one of the advantages being able to recover the file more easily than WAV/AIFF, should your recording program ever crash?