Hi all,
this is the last try I make to solve my problem. I wrote everybody, in
every site/forum, read everything, followed tutorials without any solution.
As written in the title, I have a Fast Track Pro connected via USB on
Ubuntu 12.04 LTS, I have Ardour 5.1.0 and QjackCtl 0.9.3
The problem is after many, many tries, I have the signal coming from the
card arriving in Ardour, I see the v meters move but I cannot hear any
sound in the headphones or from the speakers.
The same happens both in Hydrogen and Rakarrack.
The last thing I did is downloading the fast-track-pro.conf file from
Joe Giampaoli
<https://joegiampaoli.blogspot.it/2011/06/m-audio-fast-track-pro-for-debian-…>
tutorial. Since it's for Debian, I've only downloaded the file and
modified as per his instructions.
Then I modified it again as per instructions in this thread
<https://linuxmusicians.com/viewtopic.php?t=11016> in Linux musicians' site.
I'm also in touch with Joe but until now I haven't found any solutions
for this.
This is the parameters in QjackCtl preferences:
*Device
*hw:0 HDA Intel
hw:0,0 ALC262 Analog
-
hw:5 Fast Track Pro
hw:5,1 USB Audio #1
My laptop characteristics are the following:
* Ubuntu version 12.04 (precise) 32 bit
* Kernel Linux 3.13.0-101-generic
* GNOME 3.4.2
* RAM: 3,9 GiB
* CPU: Intel Core2 Duo CPU P8400 @ 2.26GHz × 2
Relatively to the computer audio system:
*leo@leo-R710:~$* arecord -l && aplay -l
**** Lista di CAPTURE dispositivi hardware ****
scheda 0: Intel [HDA Intel], dispositivo 0: ALC262 Analog [ALC262 Analog]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
scheda 5: Pro [FastTrack Pro], dispositivo 1: USB Audio [USB Audio #1]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
**** Lista di PLAYBACK dispositivi hardware ****
scheda 0: Intel [HDA Intel], dispositivo 0: ALC262 Analog [ALC262 Analog]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
scheda 0: Intel [HDA Intel], dispositivo 3: HDMI 0 [HDMI 0]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
scheda 5: Pro [FastTrack Pro], dispositivo 0: USB Audio [USB Audio]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
scheda 5: Pro [FastTrack Pro], dispositivo 1: USB Audio [USB Audio #1]
Sottoperiferiche: 1/1
Sottoperiferica #0: subdevice #0
*leo@leo-R710:~$* lsusb
Bus 001 Device 002: ID 1058:1100 Western Digital Technologies, Inc.
Bus 001 Device 003: ID 0ac8:c302 Z-Star Microelectronics Corp. Vega USB
2.0 Camera
Bus 006 Device 002: ID 046d:c069 Logitech, Inc.
Bus 007 Device 003: ID 0763:2012 Midiman M-Audio Fast Track Pro
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
*leo@leo-R710:~$* cat /proc/asound/modules
0 snd_hda_intel
5 snd_usb_audio
*leo@leo-R710:~$* cat /proc/asound/cards
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0xf6200000 irq 47
5 [Pro ]: USB-Audio - FastTrack Pro
M-Audio FastTrack Pro at usb-0000:00:1d.1-1, full
speed
I've downloaded a low latency kernel and installed but then I used
Ubuntu Tweak to clean my computer, as I always do after I made an
update, and it deleted also the kernel because it said it was older than
the actual.
The thing that pisses me more it's the Fast Track works perfectly on
Cubase in Windows, but I don't want to go to that crappy system for any
reason on the earth.
As I wrote, being not expert at all, I have no idea about what to do. I
would like to record with this card but if things go in this way yet,
I'll sell it and get another card suggested directly by Ardour.
There's a second hand Presonus 1818VSL so I might go for that.
The strange thing is the guy at the address I wrote above, Linux
Musicians, seens to have solved in the way he wrote.
This thing is tragic, you have no idea how tired I am.
Anyways.
We'll see if there's a way to solve it.
Thank you all.
Leo
--
ZE-Light e ZE-Pro: servizi zimbra per caselle con dominio email.it, per tutti i dettagli
Clicca qui http://posta.email.it/caselle-di-posta-z-email-it/?utm_campaign=email_Zimbr…
Sponsor:
Caselle con tuo dominio su piattaforma Zimbra, fino a 30 GB di spazio, sincronizzazione dati e backup
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=13324&d=12-11
On Mon, 14 Nov 2016 12:51:56 +0100, Ralf Mardorf wrote:
>On Mon, 14 Nov 2016 18:48:31 +1100, Erik de Castro Lopo wrote:
>>Turns out LFS got broken some time in 2013 and noone noticed until
>>now.
>>
>>The fix is here:
>>
>> https://github.com/erikd/libsndfile/commit/e4572180c3445ce1afdc9e36ab8c2163…
>>
>>There was test for this added to the test suite in the commit before
>>that one.
>>
>>Guess I should release a new version soon.
>
>:)
>
>I guess it doesn't happen that often that somebody needs audio
>files > 2 GiB, let alone that the user at the same time needs to be on
>32bit architecture, while e.g. Ubuntu flavours will drop 32bit support
>soon.
32 bit end of life plans for Ubuntu flavours:
https://lists.ubuntu.com/archives/ubuntu-studio-devel/2016-November/008226.…
The link in the above link is broken, it's
http://summit.ubuntu.com/uos-1611/meeting/22714/architecture-discussions/
Regards,
Ralf
> >>> 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.
I don't think so. Jeanette had the same problem when using jack_rec,
and I can't think of any reason why jack_capture should behave
differently when running on a 32 bit OS. It's far more likely to be
caused by the filesystem, or something else. I've cc-ed
Erik de Castro Lopo, the author of libsndfile. He probably
knows more about what could cause max file sizes of 2.1GB.
>
>
> 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
>
>
My guess is that libsndfile on 32 bit arch is not compiled
with _FILE_OFFSET_BITS set to 64, for some reason.
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
> I didn't manage to get to the bottom of which piece of software
was causing the problem.
Sorry, it is both jack_rec and jack_capture.
Both use libsndfile, and neither should behave differently
when running on a 32 bit OS.
>*From the POV of libsndfile, it has had Large File Support (which
*makes file offsets 64 bit signed values) on 32 bit systems for over
a decade.
J.C: Could it be that your libsndfile is that old?
> However, it is possible for other software using libsndfile incorrectly
> (ie using a 32 bit integer to store file offsets) to cause this sort
> of a problem, but then I would expect it to go wrong on 64 bit systems
> because `int` is 32 bits there too. However on 32 bit Linux systems,
> `long` whereas it us 64 bits on 64 bit Linux systems.
Yes, but neither jack_rec or jack_capture uses long for this (jack_capture
uses int64_t), and jack_rec doesn't even use a counter, it just writes
and writes
until it stops. jack_capture has a counter, but that counter is only
used when writing
wav files, and only used to keep track of when to start writing on a
new file when reaching
the 4GB barrier.
This one is somewhat on the smoother side, incorporating various
percussive elements.
https://soundcloud.com/nominal6/jumanmai
Enjoy. Comments welcomed.
Cheers.
Hi all :)
I only recently found this list, and did not realise there were so many
people out there making music with open source, it's pretty awesome <3
I am currently making an EP, and my mixing/mastering skills are ok, but not
exactly honed yet! I would really appreciate another pair of ears or more
in the process, so if anyone would be up for giving my mixes a listen and
giving me some feedback, that would be greatly appreciated. Please let me
know if so, but FYI timescales are quite short, so it will only be over the
next few days/week probably.
Links to my various pages are on my website (http://www.emilyfoxmusic.co.uk/),
and particularly visit my YouTube if you want to have a hear at the kind of
thing I'm doing. The EP page for info about that is on Kickstarter here:
https://www.kickstarter.com/projects/1664667971/emily-fox-makes-a-real-ep
If anyone's up for lending me a pair of ears, that would be totally amazing.
Thanks a lot,
Emily
>
> On 07.11.2016 11:32, J. C. wrote:
> > Hey hey,
> > I tried to record over long periods of time (7-9 hours), using jack_rec,
> which
> > apparently relies on libsndfile for writing audiofiles. I started out
> using
> > .wav, which broke off after 6:12:49 (2.1G). Next time, I tried using the
> file
> > extension .w64, which yielded the same result.
> >
> > So, which format, or extension, would work for such periods of time?
>
> Have you tried with jack_capture?
>
> It uses libsndfile, too for codecs, but can dump raw samples to disk if
> you tell
> it to.
>
> So, if libsndfile should be the limiting factor, try dumping the raw
> frames and
> later analyze those.
>
>
libsndfile is not the limiting factor. It's the wav format that doesn't
support large files.
(The "raw" format is also handled by libsndfile, but again, libsndfile is
not to blame here,
so that doesn't matter.)
> jack_capture -f raw -b FLOAT snoring.bin
>
>
Besides this option (and -f w64 and -f CAF which has been suggested),
jack_capture continue writing to new files in case you try to write more
data than
is supported, so you can even use the default wav format for large files.