This is probably a stupid question.
My guess is that quantisation noise is only something present between
the input signal and its digital representation, and hence no change of
the digital representations can do anything about it.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
Hello,
I have developed an audio recording application for Android, and a user is
reporting a weird noise issue. There are near-zero chances that this comes from
my code, and I'm looking for the possible cause of these noises.
Here is the sample, it's a musical flute and violin recording:
http://sound.samalyse.org/tapemachine/pulsations.wav
Listen carefully and you will here small pulsations.
I've also asked him to record a 440Hz sine. This one isn't distorted:
http://sound.samalyse.org/tapemachine/record440hz.wav
I suspect that this is a hardware issue, but I'm no expert so I can't really
tell. The phone is an HTC Incredible, which unless I'm wrong, means that the
sound components are embedded into a Qualcomm Snapdragon QSD8650 chip.
One other is that, although Android is a linux-based system, and use alsa
underneath, there's a terrible high-level Java API, which is full of various
problems which I have worked around to obtain that kind of quality. Thus, I
can't really tell what happens in there.
Have you already heard such things, and know what the cause, whether hardware or
software, is likely to be?
--
Olivier
I couldn't notice (in Germany we call it) 'pumping'. I don't think it's
caused by auto-leveling. OTOH the pulsing noise might be caused by a
strange limiter because of some peaks, but try to reproduce such a sound
using LADSPA limiters, compressors on your computer. Ok, it might be
caused on the analog domain, anyway, for analog limiters and compressors
it's the same.
Regarding to a 'half level' recording. If the user hasn't got the
equipment to reduce the level, a pocket handkerchief might help
(unfortunately it would be a pass filter too ;).
Because it's a telephone, it might be all kind of strange noise. I guess
we all know the sound a cellphone could cause to radios etc.. How do
they prevent that such noise has no impact to the cellphone's audio itself?
Hi LAD,
Since the days I installed my RME HDSP card combined with a Multiface II IO box, I have never been able to suspend / resume my PC because the multiface ends up in a weird state at resume time. I have to shut down and power off the the PC to reset everything.
Is there any improvement in recent driver iterations ? I would really like to be able to suspend / resume my PC sometimes.
Thanks for any info on the matter.
J.
Drumstick is a C++ wrapper around the ALSA library sequencer interface using
Qt4 objects, idioms and style. ALSA sequencer provides software support for
MIDI technology on Linux. Complementary classes for SMF and WRK file
processing are also included. This library is used in KMetronome, KMidimon
and KMid2, and was formerly known as "aseqmm".
Changes:
* Fixed a drumstick-sysinfo crash, when retrieving information for an
unavailable timer module.
* Fixed WRK file read implementation, allowing compilation on more
architectures.
* Added standard arguments to all the utilities/example programs.
* Added man pages for all the utilities/example programs.
* New utility/example program: drumstick-drumgrid, a simple MIDI drum pattern
editor/player.
Copyright (C) 2009-2010, Pedro Lopez-Cabanillas
License: GPL v2 or later
Project web site
http://sourceforge.net/projects/drumstick
Online documentation
http://drumstick.sourceforge.net/docs/
Downloads
http://sourceforge.net/projects/drumstick/files/0.3.2/
Regards,
Pedro
On 5/29/10, akjmicro(a)gmail.com <akjmicro(a)gmail.com> wrote:
> Hey all,
>
> Yes, grepping for the port type which appears underneath with a 'jack_lsp
> -t' will be more consistent and dependable. Or, using a python-jack lib
> function and not depending on any system shell calls. The problem then
> becomes, is the jack lib for python well documented? If so, I think that's
> the real future of jackctl.py
>
> PS Qjackctl may be lightweight, but installing the entire QT toolkit just to
> use it is not!
>
> AKJ
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Robin Gareus <robin(a)gareus.org>
> Date: Sat, 29 May 2010 14:00:52
> To: Julien Claassen<julien(a)c-lab.de>
> Cc: Aaron Krister Johnson<aaron(a)akjmusic.com>;
> <linux-audio-user(a)lists.linuxaudio.org>;
> <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: Re: [LAD] [LAU] like "qjackctl", but trimmed of all fat
>
> Hi Julien, Hey Aaron,
>
> read 'jack_lsp --help'.
>
> '-t' does not take any arguments; it just makes jack_lsp print the type.
> the filter-string only acts on the port-name (BTW, not only the
> beginning of the port-name; but it's case-sensitive: strstr() )
>
> Anyway I can reproduce the problem, some jack-midi ports show up in the
> audio-tab of jackctl20100528b.py.
>
> jackctl20100528b checks for lowercase 'midi' in the port-name instead of
> looking up the port-type. So a2jmidi for example with an upper-case M
> "Midi.." ends up in the audio-panel.
>
> Your suggestion to parse the output of 'jack_lsp -t -c' is spot on.
> the (currently 2) possible return values are (indented by tab):
>
> #define JACK_DEFAULT_AUDIO_TYPE "32 bit float mono audio"
> #define JACK_DEFAULT_MIDI_TYPE "8 bit raw midi"
>
> ..or as you suggest using the python-module for JACK may also simplify
> things and make jackctl easier to maintain.
>
> Cheers!
> robin
>
> PS. Oh, and which of qjackctl's features makes it 'fat'? it's not
> bloated in any way. I'd rather put it the other way 'round and say that
> jackctl is 'slim'. Sorry could not resist.
>
>
> On 05/29/2010 12:23 PM, Julien Claassen wrote:
>> Hello Aaron and Jack-Team!
>> There seems to be a bug in my jack_lsp. I just started a2jmidid and
>> j2amidi_bridge. when I do a jack_lsp I get all the ports.
>> When I do: jack_lsp -t midi I only get one port from jack_midi_clock,
>> but none of the other ones.
>> When I type: jack_lsp -t, I can't see a difference between the
>> jack_midi_clock port and the others:
>> jack_lsp -t
>> [...]
>> a2j:Virtual Raw MIDI 0-0 [16] (capture): VirMIDI 0-0
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-0 [16] (playback): VirMIDI 0-0
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-1 [17] (capture): VirMIDI 0-1
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-1 [17] (playback): VirMIDI 0-1
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-2 [18] (capture): VirMIDI 0-2
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-2 [18] (playback): VirMIDI 0-2
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-3 [19] (capture): VirMIDI 0-3
>> 8 bit raw midi
>> a2j:Virtual Raw MIDI 0-3 [19] (playback): VirMIDI 0-3
>> 8 bit raw midi
>> a2j:M Audio Delta 1010LT [20] (capture): M Audio Delta 1010LT MIDI
>> 8 bit raw midi
>> a2j:M Audio Delta 1010LT [20] (playback): M Audio Delta 1010LT MIDI
>> 8 bit raw midi
>> j2a_bridge:playback
>> 8 bit raw midi
>> a2j:j2a_bridge [129] (capture): capture
>> 8 bit raw midi
>> Jack MIDI Clock:midi_out
>> 8 bit raw midi
>>
>> Or is the argument "midi" only seen as the start of a port_name?
>> If so, Aaron, you must rewrite this part of jackctl (I guess you do
>> what I described, because I get exactly your output). You should rewrite
>> it using:
>> jack_lsp -t
>> And then parse the type info underneath each name. I think a simple
>> grabbing for "audio" or "midi" will do. But I guess, that in the long
>> run, using the python module for jack, will be more efficient and easy
>> to use.
>> Kindly yours
>> Julien
>>
>
--
Aaron Krister Johnson
http://www.akjmusic.comhttp://www.untwelve.org
I've got yoshimi jack session support behaving semi-sensibly with pyjacksm and
jsweeper, but there's one point I'm struggling with. Jack midi connections aren't
being stored by session save -
<?xml version="1.0" ?>
<jacksession>
<jackclient cmdline="yoshimi -d ${SESSION_DIR} -u 4" infra="False" jackname="yoshimi-yoshimi" uuid="4">
<port name="yoshimi-yoshimi:Left" shortname="Left">
<conn dst="system:playback_1"/>
</port>
<port name="yoshimi-yoshimi:Right" shortname="Right">
<conn dst="system:playback_2"/>
</port>
<port name="yoshimi-yoshimi:In" shortname="In"/>
</jackclient>
</jacksession>
I figure it has to be some deficiency in my port registration, but that seems
straightforward enough -
midi.port = jack_port_register(jackClient, port_name, JACK_DEFAULT_MIDI_TYPE, JackPortIsInput, 0);
I'm not asking for in depth debugging/analysis support here (I'll figure it out
eventually!) but I'm hopeful someone might have an 'off the top of the head'
suggestion.
cheers, Cal
I just came to understand that sourceforge sometime ago added a
setting for declaring if your project uses encryption. This, it seems
to cater to US export regulations... paah.
Now what they did is to by default set it to: 'yes' project uses encryption.
Resulting in a large part of the world not being able to access
content on sourceforge.
I won't go into the politics of this, this is not the right forum. It is done.
Though, as I'm sure very few of us uses encryption, please log in to
your sourceforge account and change this setting to 'No' so your
project remains accessible to everybody.
Regards,
Robert
Well I did the switch: jackd here is now jackdmp.. and [almost]
everything works just like before.
The motivation for this was to benefit from the re-loadable backend
feature of jackdmp for two reasons:
- to be able to quickly switch between internal and external soundcards
- have JACK sessions survive suspend/resume cycles (using dummy backend)
After some initial testing I was quite enthusiastic. It looks very
smooth on the surface. but - or course - the devil is in the details:
Calling `jack_control sm` drops existing connections to system:* ports.
OK. They may be different but here they're not. no problem: this can be
remedied with a simple shell script.
But worse: both patchage (v0.4.4) & qjackctl (v0.3.6.22) go haywire
(either 100% CPU usage, disconnect or crash) when replacing the
back-end while they're running. I have not yet found a pattern in the
app's behaviour.
Qjackctl's issue can be worked around by stopping it before doing the
switch: 'dbus-send --system /org/rncbc/qjackctl org.rncbc.qjackctl.stop'
but re-starting it after the switch fails if the qjackctl setup does not
match the current active hardware (it tries to start a 2nd jackd
instead); otherwise it works just fine.
ardour2 disconnects if I switch directly between two alsa backends.
however going alsa,hw:0 -> dummy -> alsa,hw:1 works.
Clearly there's some issue remaining to be worked out.
The good news: both mplayer and alsa-plug have no problem with me
changing the jackd-backend (while retaining sample-rate and buffersize)
even while they're playing; so I'm good most of the time :)
The scripts I use are available at http://rg42.org/wiki/jack2contol
Has anyone else ventured down that road and has a similar setup running?
Can someone reproduce these problems?
Cheers!
robin
Good evening everyone!
I was wondering, is there a difference in opening a device like
plughw:0,0
and
plug:pcm.my_own_device
I've looked in the code of aplay, but small as this tool is, it contains
still a good deal of functionality, so it seems. I've compared it to the other
code in question. there are differences. So now I think it's best to ask and
to guess, which is which and what piece of code, which function signatures are
acutally used for which purpose.
The application is question is chan_alsa from asterisk. So it's quite
limited: configured for 8kHz, 16bit (either se or le) and mono. They use a
fixed periodsize and connected buffer.
I found, that plughw:0,0 acutally let's me here things, if not really
capture input myself, but I'll pounce on that, when it's time.
I want to connect a pcm-device wired to JACK to the asterisk software, yet
it either tells me, that the argument is invalid Plug:pcm.name or plug:name)
or it gets read/write errors or it simply crashes. :-(
I've seen that they use nonblocking mode and interleaved data.
So any suggestions on that?
Warmly yours
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
