Tonight, falkTX will be the first ever guest to be interviewed on Mumble
Rumble, my show on Dark City Radio, Thursday 15th August @ 10pm GMT!
Dark City Radio is entirely powered by his OS - KXStudio - and we also make
regular use of Cadence and Claudia in running Dark City Radio so having F
as my debut guest makes perfect sense as DC may never have been possible
without him! I shall be quizzing falkTX on KXStudio, DISTRHO, Cadence,
Carla, other girls beginning with C and pretty much anything to do with
Linux (Audio) and himself.
Anyone interested in Linux audio is invited to log onto the Dark City
Mumble server during the show to take part in MUMBLE RUMBLE!
If you've never used Mumble before, see my guide to getting it set up here:
http://www.youtube.com/watch?v=_slsSlcUDcY
Thanks for listening (or taking part)!
Dan
www.darkcityradio.com
Just realized I didn't send this to the list.
On Wed, Aug 14, 2013 at 6:36 PM, Burkhard Ritter <burkhard(a)ualberta.ca> wrote:
> On Wed, Aug 14, 2013 at 10:53 AM, J. Liles <malnourite(a)gmail.com> wrote:
>> To be clear, I'm not advocating not helping others, I'm simply pointing out
>> the altruistic nature of developers responding to bug reports. The OP makes
>> it seem like he's doing the developer a big favor by engaging in the
>> reporting process--when the truth is that his 15 minute bug report generates
>> hours of work for the developer--that the developer could have most likely
>> lived his entire life without needing to do otherwise. There's an underlying
>> sense of entitlement there that is really toxic to any process of
>> collaboration.
>
> In my experience (as someone who files bug reports only very
> occasionally), doing a good bug report is more on the order of an hour
> or even more. Hence, if I find a bug in a program that I only use once
> in a while, say for three to four hours every two to three weeks (my
> use case for most programs on linux audio), filing this bug is a
> considerable time investment relative to the time I actually use the
> program.
>
> Add to this the mindset of the person you are asking to file the bug
> report: As an example, say you finally got back to making some music
> after three weeks of abstinence; you carve out the time, you spend
> four hours doing some great stuff and then at two in the morning, when
> you are just about to finish things off, you run into a show-stopper
> bug. Some basic issue that "should just work". You are extremely
> frustrated, you know you are not going to get back to doing some music
> in weeks and you are not going to file a bug report. I imagine that's
> one of the situations Louigi is taking about.
>
> Things are probably quite different when it's not a show-stopper bug,
> but a smaller glitch: You finished drafting a song sketch and are very
> happy with the software you used, but encountered a couple of smaller
> issues. Next day you might be inclined to take the time to file the
> bug report.
>
> I am not sure what can be done to improve the situation, but Harry's
> testing-buddies idea seems very reasonable. As a spin on that, a
> dedicated group of "invested" users of some program (even very small
> software projects) could actively test a new version before it is
> released. I am sure this happens to some extent and in different forms
> for most projects, but I am not sure whether there is a conscious
> testing phase and a dedicated group of testers for any but the biggest
> projects (e.g. Ardour). The goal would of course be to not have any
> basic functionality broken in released versions.
>
> Cheers,
> Burkhard
ALSAPLAYER CONFIG
$ cat .alsaplayer/config
#
# alsaplayer config file
#
# Only edit this file if the application is not active.
# Any modifications might (will!) be lost otherwise.
#
http.buffer_size=1048576
mad.parse_id3=true
main.default_interface=gtk2
main.default_output=alsa
main.multiopen=true
main.period_count=8
main.period_size=4096
main.play_on_start=false
miniG4:~$
My alsaplayer version is 0.99.80-5+b1 which is the latest version in Debian packages. Alsaplayer.sf.net shows a released version of 0.99.81. Len, from what you said, I assume this means I need to download the source and any dependencies and build it locally. I cloned the github repo and am rtfm for the source.
Before building, I removed the old alsaplayer.
root@miniG4:~# apt-get remove alsaplayer-alsa alsaplayer-common alsaplayer-text
So I took a shot at building alsaplayer. That endeavor seems to be fraught with peril. The INSTALL and README files are pretty sketchy. After running the bootstrap script and then configure, I get the following. Aside from the syntax error which is obviously a show-stopper, should I be worried about the other not found scripts or programs?
root@miniG4:~/alsaplayer# ./configure
checking build system type... powerpc-unknown-linux-gnu
checking host system type... powerpc-unknown-linux-gnu
checking target system type... powerpc-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... none
checking dependency style of gcc... none
checking how to run the C preprocessor... gcc -E
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether NLS is requested... yes
checking for msgfmt... no
checking for gmsgfmt... :
checking for xgettext... no
checking for msgmerge... no
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
./configure: line 6162: gt_INTL_MACOSX: command not found
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) no
checking whether g++ accepts -g... (cached) no
checking dependency style of g++... (cached) none
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking whether gcc and cc understand -c and -o together... yes
checking whether make sets $(MAKE)... (cached) no
checking for ANSI C header files... (cached) yes
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking for unistd.h... (cached) yes
checking linux/cdrom.h usability... yes
checking linux/cdrom.h presence... yes
checking for linux/cdrom.h... yes
checking sys/soundcard.h usability... yes
checking sys/soundcard.h presence... yes
checking for sys/soundcard.h... yes
checking sys/audioio.h usability... no
checking sys/audioio.h presence... no
checking for sys/audioio.h... no
checking audio/audiolib.h usability... no
checking audio/audiolib.h presence... no
checking for audio/audiolib.h... no
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking mad.h usability... no
checking mad.h presence... no
checking for mad.h... no
checking id3tag.h usability... no
checking id3tag.h presence... no
checking for id3tag.h... no
checking FLAC/stream_decoder.h usability... no
checking FLAC/stream_decoder.h presence... no
checking for FLAC/stream_decoder.h... no
checking for pthread_create in -lpthread... yes
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... yes
checking for madvise... yes
checking for doxygen... false
configure: WARNING: *** doxygen not found, docs will not be built
checking for libmikmod-config... no
checking for libmikmod - version >= 3.1.7... no
*** The libmikmod-config script installed by libmikmod could not be found
*** If libmikmod was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the LIBMIKMOD_CONFIG environment variable to the
*** full path to libmikmod-config.
checking for Ogg... no
*** Could not run Ogg test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means Ogg was incorrectly installed
*** or that you have moved Ogg since it was installed. In the latter case, you
*** may want to edit the ogg-config script:
checking for Vorbis... no
*** Could not run Vorbis test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means Vorbis was incorrectly installed
*** or that you have moved Vorbis since it was installed.
checking for glBegin in -lGL... no
checking for glBegin in -lMesaGL... no
checking GL/gl.h usability... no
checking GL/gl.h presence... no
checking for GL/gl.h... no
checking GL/glx.h usability... no
checking GL/glx.h presence... no
checking for GL/glx.h... no
checking for FLAC__stream_decoder_new in -lFLAC... no
checking for FLAC__stream_decoder_init_ogg_stream in -lFLAC... no
checking for mad_stream_init in -lmad... no
checking for id3_file_open in -lid3tag... no
./configure: line 18675: syntax error near unexpected token `JACK,'
./configure: line 18675: `PKG_CHECK_MODULES(JACK, jack >= 0.118.0, have_jack=yes, have_jack=no)'
On Aug 14, 2013, at 9:48 AM, linux-audio-user-request(a)lists.linuxaudio.org wrote:
> Message: 9
> Date: Wed, 14 Aug 2013 16:57:09 +0200
> From: Clemens Ladisch <clemens(a)ladisch.de>
> To: linux-audio-user(a)lists.linuxaudio.org
> Subject: Re: [LAU] alsaplayer error using USB Audio DAC
> Message-ID: <520B9AC5.7030109(a)ladisch.de>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Roger Weinheimer wrote:
>> the problem is with alsaplayer.
>
> Please show the contents of ~/.alsaplayer/config.
>
>
> Regards,
> Clemens
Hi folks,
This is related to recording, and my recordings are made on linux, so,
it is tangential to all of these lists. :-)
I own an ART tube pac, which is a preamp compressor combo unit.
It is the first generation of this unit I believe. I've just started
using this unit.
Anyway, I'm hearing a low level hum, sortof like a grounding hum.
Does anyone else use the ART line of pres? Has anyone had trouble with them?
The unit uses 2 tubes and I'm sure they aren't high quality tubes.
Could a lower quality tube cause a low level ground hum?
The unit has a grounded plug, and I can't seem to get rid of the hum
by unplugging other components, but when I mute the unit through my
sound card, the hum is decreased. The hum is audible in silences on
my tracks, so I know it's not just my playback system.
Now, before you go on about how the ART pre is cheap and crappy. I
know it's a budget pre, that's why I can afford it. I'm only looking
for constructive ideas, or similar experience.
Thanks so much!
Rusty
CAPS 0.9.10
===========
http://quitte.de/dsp/caps.html
The CAPS Audio Plugin Suite, a LADSPA library comprising classic sound
effects, various signal generators and guitar tone processing, sees
another update containing some bug fixes, minor sound improvements in
various places and a new plugin, "Spice", which, strangely, appears
not to be an exciter.
http://quitte.de/dsp/caps.html#Spice
In addition, the package documentation has been revised and some
errors corrected.
http://quitte.de/dsp/caps.html#Download
Enjoy!
Something some people find disconcerting about me is that sometimes I'll
totally freak out about something that might be taken as a given by
others, as though I've discovered fire, just because it's dome something
wonderful for me.
So...I'm going to freak out like I've discovered fire.
Don't ask me why it took me this long, but I just tried the parametric
equalizer plugins from Calf. WOW. So this is the clean transparent mix
I've been wanting forever. In just a few minutes, I've been able to do
things with this plugin that I couldn't achieve in hardware (and I've
got a lot of hardware). Whoever did this obviously knows more than most
about how to write audio filter algorithms, because...wow.
Their Sourceforge page doesn't seem to list anywhere that one can
donate, but I'm impressed enough that I would. So, if any of you Calf
audio plugin people are out there on LAU, just want to let you know I
think your parametric EQ is worth paying for all by itself.
Ok...I'm done now. :)
(Addendum: Has anyone else besides me had trouble getting some plugins
to same recallable presets? You save, and then try to recall, and
nothing happens. Still, it saves its current settings in your project,
and I suppose that's all that matters.)
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ Sr. UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ James Franck Institute + Shakespeare. Now, thanks to the Internet,
+ Materials Research Ctr + we know this is not true." -Robert Wilensky
Hi.
I just wanted to let you know that I have been working on a soft synth
called rogue.
https://github.com/timowest/rogue
It's not yet feature complete, but it would be great to get some external
feedback concerning sound, stability and visuals.
Br,
Timo Westkämper
I meant to share this last night but sidetracked. These are the specs from the DAC packaging, fwiw. Does this help to address format/capabilities questions?
https://www.dropbox.com/s/yxgtmfspneva9io/dacSpecs.pdf
On Aug 9, 2013, at 5:12 AM, linux-audio-user-request(a)lists.linuxaudio.org wrote:
> Date: Thu, 8 Aug 2013 10:58:49 -0400
> From: Paul Davis <paul(a)linuxaudiosystems.com>
> To: len(a)ovenwerks.net
> Cc: Linux Audio Users <linux-audio-user(a)lists.linuxaudio.org>
> Subject: Re: [LAU] alsaplayer error using USB Audio DAC
> Message-ID:
> <CAFa_cKna20vy2MD=Ty=NBP=cdPn6oD9LPvDsCDT78Pg+8w7Piw(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Aug 8, 2013 at 10:53 AM, Len Ovens <len(a)ovenwerks.net> wrote:
>
>>
>> Generally for trouble shooting I would hit the card directly:
>> alsaplayer -i hw:1,0 filename.flac
>>
>> aplay --device=hw:1,0 filename.flac
>>
>
> aplay can't handle anything but straight PCM formats. in addition, using
> hw:XXX means that the requested data format MUST match the hardware
> capabilities. if you ask for a sample rate or channel count not supported
> by the hardware, the device configuration will fail. this is why the
> "default" device with ALSA is never hw:XXX but at minimum plughw:XXX (which
> can do just about any format conversion necessary).
