Hello.
I’m using the HP probook with 6Gb of RAM, core i3 running OpenSuse 12.2.
For recording I want to use Lexicon Alpha USB interface.
All recordings, made through this interface are sound like they’ve made in tunnel. Is there any solutions for this problem specific for Suse or Linux?
In FAQ, I’ve found solution only for windows. Dealing this problem in the same way in Suse didn’t gave any results.
The first thing to check is that you really are recording (only) through the Lexicon Alpha and that audio is not getting in anywhere else (for example through a built-in microphone or web cam). Make a recording and turn the “Chan 1” and “Chan 2” gains down to minimum, then make a lot of noise around the computer - the recording should be silent.
steve, thank you for a reply.
During the recording, sound goes only through Lexicon.
I’ve noticed that when I’m recording single track, the quality is good and there’s no problems with sound.
But when I have previously recorded track (drums for example) in the project, new track sounds like recorded in the tunnel. If my PC were old enough, I could suppose that I have a lack of RAM. But 6 Gb, I think is quite enough…
What are you recording? Do you have some sort of microphone plugged into the Lexicon Alpha?
I’ve tried to record in different configurations:
Passive bass guitar - Lexicon - Notebook
Passive bass - Booster - Lexicon - Notebook
Active bass guitar - Lexicon - Notebook
Active bass - Booster - Lexicon - Notebook
Guitar - Booster - Lexicon - Notebook
Noname mic - Lexicon - Notebook
And evry time - single track record is good, multitrack record is freaky.
Maybe I have a problem in configuration of Suse or Audacity?
In a new Audacity session, generate some silence (Generate menu)
Then record a track.
Does that sound good or like it’s in a tunnel?
Could you post short sample of the problem, preferably in WAV format.
(How to attach files: https://forum.audacityteam.org/t/how-to-attach-files-to-forum-posts/24026/1)
So, here’s two files:
First one - single track record, to give you an idea, what I have recorded on the second
The second one - record with two tracks - first track is generated silence, second is similar to previous file
As you can hear - tunneling problem is here.
Thanks, that illustrates the problem clearly, but I wouldn’t describe that as sounding like “in a tunnel”. The audio is chopped up into pieces with gaps between.
The size and even spacing of the gaps is unusual - it looks like your Lexicon Alpha is not able to perform playback and recording at the same time (“duplex” mode).
My suspicion would be that the problem lies with the USB connection.
Do you have any other USB devices connected?
Don’t use a USB hub.
I have no other USB devices connected at all. Also I don’t use the USB hub.
When I’m trying to record through Lexicon and play through notebook’s sound card, I’ve got another problem - the track recorded only for one or two secnds, and after this playback and recording stops automatically.
I’m just want to record my musical experiments, and both this problems discourage me from this 
And is there any desicion, how can I hear the previously recorded tracks during recording new one?
That should be enabled in Audacity by default.
“Transport menu > Overdub” needs to be enabled (selected).
Do you know if OpenSUSE uses PluseAudio as the default sound system?
There is another topic on the forum where a user is getting similar problems with a USB audio device on OpenSUSE 12
https://forum.audacityteam.org/t/saving-usb-output-from-a-fender-mustang-i-amp-linux/25962/9
Steve, thank you for feedback!
I’ve tried the USB solution from parallel tread, then changed latency (audio to buffer) to 300 milliseconds, and at least, I’ve got the full waveform, without silence.
With audio to buffer parameter equal 200, the problem remains the same.
Will such time affect the recording when I have to be synchronized with drums and other?
Suse is using PulseAudio, at least in KDE environment, which I use.
That sounds good, though there does seem to be something a bit amiss that you need to go that high, however, if it is working then it’s working.
If you are using no other audio applications at the same time then you can bypass PulseAudio by directly setting the input and output devices in the Device Toolbar
The options “default” or “Pulse” will use PulseAudio.
It may be worth checking to see if it works better with or without PulseAudio. (Make a note of your current working settings before you change them 
)
It will make a difference to the “recording latency”, but Audacity can compensate for that if you set it up. See here for how to calibrate the recording latency compensation: Audacity Manual
Note that if you change any of the recording settings you will probably need to recalibrate the latency compensation so that multiple recorded tracks are correctly synchronised.
Steve, I’m always setting the input and output device in toolbar, because, if I don’t make this, I can record only two o three seconds of audio. I think this is specifics of OpenSuse. Friend of mine have Ububntu on his desktop, and he does not have such problems with Audacity.
I’ve tried to install Ardour, and during the installation it told me, that my notebook is using something like the dynamic frequency mode. As I understand this is the option which changes processor frequency in dependence of power supply and other things. Also, Ardour told me that I have limited memory allocation for running programs.
I will try to change the system configuration according to its requirements, and then run Audacity (Audacity is more handy for me). After this I will restore default Audacity settings and will try to record something. I’ll write a post about the results asap. 
That would be very useful. Thanks.
The quick and easy way to restore default settings in Audacity is to delete the file:
~/.audacity-data/audacity.cfg
Sorry for my long silence.
I’ve tried the things, which ardour suggested me.
I’ve increased the amount of locked memory from 64 kB to 2048 kB with command ulimit -l. - No effect. On the second track the same old problem.
I’ve tried to change power and performance settings, but they already on highest level. (I don’t have as much experience with Linux, as I want, but through GUI all set on highest performance). Maybe this was a standard ardour advice for notebooks. So, the performance settings does not changed situation at all.
At last, I’ve decreased Audio to buffer to 10 milliseconds, and latency correction to -10. Everything is working! and 10, 0 also works.
If I use buffer 100 milliseconds and latency correction -100 and -90, I have periodical lost in sound, like before.
The situation is quite strange for me: if I use the big Audio to buffer value, everything works. If I use small value - everything works. If I use near-default value, sound is periodically lost.
As I understand, the recorded audio going into buffer in RAM, the amount of sound in buffer declared by preferences (10 milliseconds, for example) and then, with latency correction it goes to hard disk and Audacity. Am I right?
So what will load system more? the big buffer or small? Can you tell me the pros and cons of big (300 ms) and small (10 ms) audio to buffer values?
Also, I’ve tried to start Audacity through terminal (I know, I have to do this earlier, but GUI is so beautiful 
)
I have such errors:
bonelick@Gobbo-Book:~> audacity
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2217:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_dmix.c:957:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3875
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3875
Expression 'stream->playback.pcm' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 3875
(Audacity:9352): Gtk-CRITICAL **: IA__gtk_widget_get_state: assertion `GTK_IS_WIDGET (widget)' failed
But audacity starts and everything is working.
as I understand this is an old error in Suse, and it have no solution to this moment.
That seems pretty strange to me too.
Increasing the buffer size to avoid gaps in the audio makes sense, but I’d have expected small values to make the problem worse. All I can speculate is that with small values something else may be taking over doing the buffering (perhaps PulseAudio), but I’m only speculating - it does seem odd that it should work at all with very small buffer settings.
Close.
The recorded audio goes into a RAM buffer (100 ms by default) before being written to disk.
All of the data is written to disk unaltered and creates the audio track in Audacity.
When writing the second (or subsequent) track, if nothing was done to correct it, the second track would be delayed a bit compared with the first track due to the time taken for the audio to work its way through the electronics, through the software, through the RAM buffers and finally written to disk.
Audacity compensates for this delay by shifting the track a little to the left when the recoding stops.
If you look carefully you can sometimes see Audacity doing this.
The amount that the new track is shifted is set by the “Latency Correction” setting.
A larger buffer allows the computer more time to write the data to disk.
If there were no buffer then the data would need to be written to disk immediately and constantly. This is often not possible because the drive needs to find space to write the data and sometimes needs to go and read or write something else for some other program or process.
When set to 100 ms, the buffer must be written to disk within 100 ms. This is usually enough leeway to allow the system to write the data to disk without dropping any data.
If the buffer is too small, then the buffer will become full and incoming audio data will have nowhere to go, so data will be lost and the recording will stutter.
If 100 ms is stuttering then 300 ms provides a lot more time for the data to be written.
If 100 ms is stuttering then 10 ms provides a lot less time for the data to be written - the stuttering should be a lot worse or recording stop altogether - It’s a mystery to me why this works on your machine 
Apart from the last line they are not really “errors” and are nothing to worry about. They are just messages indicating that Audacity is looking to see what sound system is running and available on your computer. It checks against a list of possibilities, discarding them one by one until it finds something that will work.
I’m not sure what the last line means but to me it looks like a minor bug in wkGTK.