Hi list,
I have been search the archives and the web a bit and it seems there is
no easy way to route html5 audio playback from firefox through jack on
Debian testing.
Is this still the case or has there been recent development that might
enable it? What would have to be done to make it work? This
functionality is the last piece in my puzzle to finally get rid of
flash.
thanks for pointers,
P
Hi there!
ShowQ is a unique cue-player for Linux-Audio-Users. I use it as a core
application for my theater activities.
Even in the linux-community it's not a very well known application,
although there's no other linux-program (I know) if you need a
one-shot-audio-player with features like f.e. programmable fade-in,
fade-out, no matter if you want it time-based or triggered by space (or
another key).
It can do a lot more - ShowQ has MIDI-support. Although I never tested
this feature, it should be possible to control any application with
MIDI-support. QLC(+) f.e. - or maybe some video-players do support MIDI
- I don't know...
Yeah, of course, ShowQ is not a drop in replacement for QLAB, but
speaking about audio it fits quiet perfectly in my setup.
ShowQ is in the Debian (and Ubuntu?) repositories, it's written in C++
and of course released under the terms of the GPL. Although this app is
quiet useful for technicians like me, the development stopped years ago.
I am not a coder, but I do my best to keep this project alive. On the
Debian bug-tracker I write bug-reports for ShowQ, hoping that on one
hand it's useful for other users to work around problems, on the other
hand that someone fixes them.
Last time I reported a bug Jaromír Mikeš the Debian-maintainer of ShowQ
wrote that he is not able to fix the bugs and he would like to kick
ShowQ. Of course, he also would like to package an alternative if there
would be some he could package.
I don't know any - so my linux-based theater setup is about to be killed
one day when ShowQ wouldn't compile on my debian machine, anymore.
So, what do I want from you?
Test ShowQ! Maybe it's the app you've been missing for a long time!
And if you're a coder with C++-skills, check out my bugreports on
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=showq
- maybe you've got the clue...
OR: Got an alternative to ShowQ? You're welcome!
Greets!
Mitsch
On Dec 30, 2016 08:29, Will Godfrey <willgodfrey(a)musically.me.uk> wrote:
>
> On Sun, 18 Dec 2016 15:46:34 +0000
> Will Godfrey <willgodfrey(a)musically.me.uk> wrote:
>
> > On Sun, 18 Dec 2016 22:38:31 +1100
> > Roger <gurusonic(a)gmail.com> wrote:
> >
> > > On 18/12/16 19:46, Will J Godfrey wrote:
> > > > All of this has happened since that latest fetch from debian testing :(
> > > > Maybe I'm imagining things, but we seem to be getting a lot more breakages
> > > > and general strange behaviour from debian these days.
> > > >
> > > Debian Stretch is in freeze transition preparing for next release. Soft
> > > freeze happens on 5 Jan so many packages may be pushed to beat this
> > > deadline causing testing to be at a fragile stage currently.
> > >
> > > https://www.debian.org/News/weekly/2016/04/
> > >
> > > Doesn't help fix your issue but may help explain why it happened.
> > >
> > > Roger
> >
> > Didn't think of that :(
> >
> > Thanks, I can get round things for now.
> >
>
> Hmmm, my normal state of mild confusion has now progressed to considerable
> agitation!
>
> As an experiment I tried using jackd1. Result, none of these messages. However
> debian doesn't provide headers for this so I can't compile against it.
>
> Go back to jackd2 (lot's of arsing about to do that) and once again I get a
> continuous stream of messages even when there is nothing running except
> qjackctl, so I'm wondering if the nice people at debian have inadvertently
> compiled it with a debug switch enabled.
>
> Is there such a switch, and can it be disabled without re-compiling.
>
> I generally avoid compiling low-level stuff - I don't want to end up having to
> also compile all the kit that's dependent on the debian installs.
>
> Below is a few *seconds* worth from qjackctl's message window.
>
> Jack: JackEngine::ClientNotify: no callback for notification = 4
> Jack: JackEngine::ClientNotify: no callback for notification = 4
> Jack: JackExternalClient::ClientNotify ref = 2 client = qjackctl name =
> qjackctl notify = 4 Jack: JackSocketServerChannel::Execute : fPollTable i = 2
> fd = 10 Jack: JackClient::ClientNotify ref = 2 name = qjackctl notify = 4
> Jack: JackClient::kGraphOrderCallback
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
> Jack: JackSocketServerChannel::Execute : fPollTable i = 1 fd = 9
> Jack: JackSocketServerChannel::Execute : fPollTable i = 2 fd = 10
FWIW, I updated to JACKD2 from testing last night. I use mplayer on command line to play through JACK. And get the same results.
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
Hello,
This is about Jaki Liebezeit, drummer of the seminal 70s German band
Can, who passed away earlier this month. The piece was not made to
sound like Can. It was made with the 'thought of'.
https://soundcloud.com/nominal6/flownotion
Cheers.
Sorry for the wrong list... Forwarded to the proper list.
-------- Forwarded Message --------
Subject: ROLI Seaboard RISE
Date: Fri, 27 Jan 2017 16:09:24 +0000
From: Felipe Ferreri Tonello <eu(a)felipetonello.com>
To: Linux Audio Announce <linux-audio-announce(a)lists.linuxaudio.org>
CC: John Murphy <rosegardener(a)freeode.co.uk>
Hi John,
I just saw your email to the LAU list and I would like to reply to it
but I couldn't since I was not registered to this mailing list. So I
have to create a new thread, sorry for the flood. :/
TL;DR: Don't worry about updating the Kernel, ALSA or anything. MIDI
over BLE is part of the BlueZ user-space and it is not released yet. So,
if you are too eager to try it out (I recommend), you have to build
bluetoothd yourself, check my blog for more information[1]. MIDI over
USB works just fine.
Technical stuff:
* The Bluetooth Low Energy support for MIDI is not in the Linux Kernel.
It is part of BlueZ's bluetoothd daemon, so you need to update BlueZ
user-space only. The thing is that it was not released yet, so if you
want the feature you have to compile bluetoothd yourself for now.
* The MIDI-USB is in the Linux Kernel, but you don't need to update that
since the drivers there are working for a long time now (thanks to
Clemens Ladisch and others). The changes for v4.9 I mentioned on my blog
impacts only the *gadget* driver only! The gadget driver is used for USB
devices (keyboard) and not USB hosts (your computer).
* You can ignore those pulseaudio errors on your log. That is because
pulseaudio tries to handle any ALSA Card that exports a PCM device and
since the MIDI device opens a new ALSA Card but it only exports a MIDI
device, it will fail to open it.
So, you can use your Seaboard RISE with USB just fine on Linux.
PS: How do you find using your RISE? Are you interested in having the
Equator synth and Dashboard applications on Linux? If so let me know, I
can arrange these for you (or anyone else). We, at ROLI, want to release
a beta version for Linux, it will be great to know if users are
interested in it.
[1]
https://blog.felipetonello.com/2017/01/13/midi-over-bluetooth-low-energy-on…
--
Felipe
Have any of you guys managed to get the kxstudio repositories installed on
a plain-jane ubuntu 16.10?
--
**** Listen to my FREE CD at http://www.mellowood.ca/music/cedars ****
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: bob(a)mellowood.ca
WWW: http://www.mellowood.ca
Can anyone recommend one of these that's reasonably small and robust - not
requiring a second mortgage!
I don't want keys, but programmable push buttons and sliders/knobs. A joystick
would be icing on the cake.
Thanks in advance.
Will.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Hello linux-audio users,
I recently acquired a roland a-500s midi keyboard and I have problems
using it under linux. When I connect the device via usb, dmesg tells me
this:
[ 68.100184] usb 3-1: USB disconnect, device number 2
[ 73.700119] usb 3-1: new full-speed USB device number 3 using uhci_hcd
[ 73.860157] usb 3-1: New USB device found, idVendor=0582, idProduct=010d
[ 73.860162] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 73.860165] usb 3-1: Product: A-500S
[ 73.860169] usb 3-1: Manufacturer: ROLAND
[ 73.867172] snd-usb-audio: probe of 3-1:1.0 failed with error -5
And this is the relevant portion of lsusb -v:
Bus 003 Device 003: ID 0582:010d Roland Corp. A-500S
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x0582 Roland Corp.
idProduct 0x010d A-500S
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 150mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 3
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
I am running debian stable (8) and my machine is a lenovo thinkpad
x60s, any help appreciated!
-F
On Jan 28, 2017 22:20, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:
>
> On Sun, 29 Jan 2017 09:14:07 +0100, Ralf Mardorf wrote:
> >On Sat, 28 Jan 2017 17:55:40 -1000, david wrote:
> >>So I wonder. Is there some sort of upper speed limit in the MIDI
> >>standard? Is the MIDI standard smart enough to negotiate speeds if
> >>various MIDI devices differ? Or was the MIDI standard strict in
> >>saying that your device must operate at this official speed?
> >
> >You are aware that MIDI data simply is send and received without a time
> >stamp and without any sync. The software checks if an ACIA/UART
> ^^^^^^^^^^^^^^^^ English isn't my native language, this
> phrase might not be that good, but it anyway is to the point.
>
> >register reports that a byte was received by a short machine language
> >endless loop. The endless loop is only interrupted by a branch, if a
> >byte was received, to read the byte and then to continue the endless
> >loop. On old computers such as the C64 a lot of MIDI operations were
> >done by even disabling IRQs. The 65xx chips have a command to disable
> >timer and break command/flag IRQs, named SEI. One MIDI interface must
> >use the same rate on both ends, the receiver and transmitter, but if
> >you use different interfaces you could ignore the MIDI standard and
> >chose any other rate, as long as sender and receiver chose the same
> >rate. IOW one interface could not communicate with several MIDI
> >interfaces using different rates.
Sorry, all I know about MIDI is how to connect cables, channels, program banks, patch sets. I have a vague idea that old-style MIDI cables had a max data rate comparable to telephone line modems.
Used to program on a C64. I wrote a Mandelbrot set generator in 6510 assembler. Had to turn off interrupts to get processing time down to many many hours vs the days it took in BASIC.
Fun times.
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
