The PCI card I'm working with was made to receive the signal as a 32 bits frame (16 bits by channels) each time I write to the file device so I have to turn the src_data.data_out frames (2 floats) into a unique 32bit unsigned long and write it:
1) "unsigned long frame;" : I declare an unsigned long that will receive the entire frame.
2) "frame = (unsigned long) ((src_data.data_out[sent]))>>16;" : I convert the float at the index equal to sent and initialise the frame with it. So my frame look like this 0000000000000000XXXXXXXXXXXXXXXX Where Xs represent one channel signal.
3) "frame |= (((unsigned long) (src_data.data_out[sent+1])) & 0xFFFF0000);" Apply a mask to the 16 first low bits of the data_out float value and aplly a OR between it and frame. It should look like this :
yyyyyyyyyyyyyyyy0000000000000000 | 0000000000000000XXXXXXXXXXXXXXXX = YYYYYYYYYYYYYYYYXXXXXXXXXXXX
Where Ys is the other channel signal.
Is it clear enough,I hope so :)
I have to emphasize that this stuff seems to work because when I send the src_data.data_in frames buffer this way, the signal is perfect.
> Message du 11/02/08 14:12
> De : "Erik de Castro Lopo" <mle+la(a)mega-nerd.com>
> A : linux-audio-dev(a)lists.linuxaudio.org
> Copie à : "Mathieu Dalexis" <dev.audioaero(a)orange.fr>
> Objet : Re: [LAD] (no subject)
>
> Mathieu Dalexis wrote:
>
> > unsigned long frame;
> > frame = (unsigned long) ((src_data.data_out[sent]))>>16;
> > frame |= (((unsigned long) (src_data.data_out[sent+1])) & 0xFFFF0000);
>
> Sorry, but what is all this stuff?
>
> Erik
> --
> -----------------------------------------------------------------
> Erik de Castro Lopo
> -----------------------------------------------------------------
> "Projects promoting programming in natural language are intrinsically
> doomed to fail." -- Edsger Dijkstra
> ---------------------------------------------------------------------------------------
> Orange vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Hello,
I try to perform dynamic upsampling on a signal (SR=44,1kHz) to double the sample rate.
Here is the code I wrote to test it. It works using a raw audio file (cdparanoia -r 1) with a 1Khz sin signal.
When I look to my output signal with an oscilloscope it looks quite good but I get some noise (glitches?) that makes it really sound bad.
Is there something I do wrong ? Is it a libsamplerate problem ?
**************************
******My code*************
**************************
#include <stdio.h>
#ifdef HAVE_STDLIB_H
#include <stdlib.h>
#endif
#include <math.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <samplerate.h>
int
main(int argc, const char *argv[])
{
 int TAILLEBUF = TAILLEBUF;
 int TAILLEBUF_OUT = TAILLEBUF;
 int16_t * p_readbuf= (int16_t *) malloc(sizeof(int16_t)*TAILLEBUF);
 float * pf_readbuf= ( float *) malloc(sizeof(float)*TAILLEBUF);
 float * pf_writebuf= ( float *) malloc(sizeof(float)*TAILLEBUF_OUT);
 int fini=0;
 int finiRead=0;
 int fd,fdread;   /* sound device file descriptor */
Â
 struct timeval tv;
 tv.tv_sec = 0;
 tv.tv_usec = 120000;
 int error;
 SRC_STATE * src_state;
 SRC_DATA src_data;
 src_data.src_ratio = atoi(argv[3]);
 src_data.input_frames=0;
 src_data.end_of_input = 0;
 src_data.data_out = pf_writebuf;
 src_data.output_frames=TAILLEBUF_OUT/2;
 src_state = src_new(2,2,&error);
 /* open sound device I'm working on my own sound card */
 fd = open("/dev/AudioDriver/data", O_WRONLY);
 if (fd < 0) {
   perror("open of /dev/AudioDriver/data failed");
   exit(1);
 }
/*My raw sound file*/
 fdread = open("./cdda.raw", O_RDONLY);
 if (fd < 0) {
   perror("open of cdda.raw failed");
   exit(1);
 }
 fd_set writefds[1];
 FD_ZERO(writefds);
 FD_SET(fd, writefds);
 int k=0;
      while (!finiRead) {
   /* read TAILLEBUF/2 Frames */
   int j;
   if(read(fdread,p_readbuf,TAILLEBUF*sizeof(int16_t))!=TAILLEBUF*sizeof(int16_t))
         finiRead=1;
  Â
   int i=0;
   /*Convert from 16bit integer to Float*/
         for(i=0;i<TAILLEBUF;i++)
    {
      pf_readbuf[i]=((p_readbuf[i])<<16) ;
      }
     Â
   if(src_data.input_frames==0)
    {
      src_data.data_in = pf_readbuf;
      src_data.input_frames=TAILLEBUF/2;
    }
   tv.tv_sec = 0;
   tv.tv_usec = 120000;
   fd_set writefds[1];
   FD_ZERO(writefds);
   FD_SET(fd, writefds);
   while(select(fd+1, NULL, writefds, NULL, &tv)!=1){  Â
    tv.tv_sec = 0;
    tv.tv_usec = 120000;
    fd_set writefds[1];
    FD_ZERO(writefds);
    FD_SET(fd, writefds);
   }
   int sent = 0;
   Â
    if((error = src_process(src_state,&src_data))!=0)printf("error\n");
  Â
    while(sent < src_data.output_frames_gen)
      {
       /*Convert my 2-floats frame to an unsigned long frame containing my to channels*/
        unsigned long frame;
        frame = (unsigned long) ((src_data.data_out[sent]))>>16;
        frame |= (((unsigned long) (src_data.data_out[sent+1])) & 0xFFFF0000);
        if(write(fd, &frame, sizeof(unsigned long))!=sizeof(unsigned long))
      {fini = 1;
      }
        sent += 2;
      }
 exit(0);
}
****************************
****************************
****************************
I hope that you can understand my english and that my code is clear enough for you to help me.
Thanks in advance.
Mathieu
I received a private reply to my request regarding
a jack-midi equivalent to pmidi. This may be of
interest to others as well.
Jpmidi
<http://www.geocities.com/kellinwood/jpmidi/index.html>
does the job nicely.
Unlike pmidi, jpmidi is a 'resident' program - it
creates it own command prompt, allowing e.g. to
connect it and start / stop playing (it controls
and follows jack's transport).
Given this it's odd that it doesn't have a 'load'
command. To switch to another midi file you have
to quit and restart.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
LAC 2008: bandwidth to burn and volunteers needed
The 6th annual Linux Audio Conference is taking place in Cologne, Germany, Feb
28th to March 2nd, 2008. As with each previous year this year's conference will
be streamed live over the internet in ogg theora via icecast. The stream server
is up at: http://lac2008.khm.de:8000/
There is nothing to see at the moment, but keep checking over the coming days
as we hope to have a test stream up soon.
This year we are in the unique situation of having a Gigabit link donated by
CITIZENMEDIA: http://www.ist-citizenmedia.org/ They have asked us to use up as
much of their bandwidth as we can so they can see how well the link performs.
This year the core team, Joern Nettingsmeier and myself, are recruiting
volunteers to spread the workload. To that end we have set up a mailing list
and irc channel to coordinate our efforts. We will also have a wiki shortly.
If you will be coming to Cologne for the conference please consider signing up
to help. If you are not coming, please enjoy the fruits of our labors by
watching the streams and participating via irc.
stream team mailing list: http://zhevny.com/mailman/listinfo/lac-streams
general conference chat: #lac2008 on irc.freenode.net
stream team tech talk: #lac2008-tech on irc.freenode.net
Thanks,
Eric Rz.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
The Aqualung development team is pleased to announce the latest
release of the Aqualung music player.
Aqualung is an advanced music player originally targeted at the
GNU/Linux operating system, today also running on FreeBSD, OpenBSD and
Microsoft Windows. It plays audio CDs, internet radio streams and
podcasts as well as soundfiles in just about any audio format and has
the feature of inserting no gaps between adjacent tracks.
The ChangeLog is included below.
Please note that our website has moved to http://aqualung.factorial.hu
Please update your links and bookmarks.
Enjoy,
Tom
2008-02-10 Tom Szilagyi <tszilagyi at users dot sourceforge dot net>
* Aqualung 0.9beta9.1
http://aqualung.factorial.hu
This is a bugfix, stability and performance oriented release also
containing a few updates to existing functionality. By using this
version, your Aqualung will be more stable, and in some cases
significantly faster. All users are encouraged to upgrade.
The project homepage has moved to http://aqualung.factorial.hu
Please upgrade your pointers and bookmarks.
Notable changes:
* Playlist code refactoring for improved performance. Please note
that incompatible changes have been made to the playlist format:
this means that your old playlists won't be parsed, you'll have to
re-create them.
(NOTE: Music Store contents are unaffected. If we ever change the
Music Store format in a backward-incompatible way, we will provide
tools to migrate your precious store data.)
* Fix threading problems that caused random crashes for some users.
* Fix lurking bug that sometimes resulted in getting stuck at the
beginning of a track when Sinc interpolator sample rate converters
were used.
* Modified the way of opening ALSA output to achieve non-exclusive
driver access.
* New, more versatile title string generating templates. Make sure
to check the documentation.
* Added option to periodically save playlist.
* Several fixes concerning command line file and playlist loading,
esp. with the -L flag.
* Better metadata handling for external files in playlist.
* Increment CDDB revision number on resubmitting an existing
disc. This is essential for correcting existing CDDB entries,
otherwise the CDDB server rejects the submission. The latest CVS
version from http://libcddb.sf.net is required for this to work
(Aqualung-Win32 is built with this version).
* OpenBSD-related portability fixes. Aqualung should now compile
cleanly and be fully functional OOTB on OpenBSD 4.2.
* Updated German, Hungarian and Italian translations. Added
Russian translation.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey LADs,
Looking at the FOSDEM 2008 schedule I found a talk [1] about xaudio [2].
I was surprised that xaudio has not yet popped up on LAD or LAU (or have
I missed it?). Has anyone checked that out already? Besides Desktop
integration this could become quite interesting for tight audio/video sync.
robin
[1] http://www.fosdem.org/2008/schedule/events/xorg_xaudio
[2] http://www.chaoticmind.net/~hcb/murx/xaudio/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHruVseVUk8U+VK0IRAq7aAJ0aLYUOI67ly+X2AER9wx7WxWO4sQCdGiXk
MhmWLEnzjviURqAe111AhKI=
=t7po
-----END PGP SIGNATURE-----
Here comes the third part of our exciting LASH trilogy. Unfortunately I
lost the previous threads' mails while migrating from kmail & POP to
thunderbird & IMAP, so I'll have to start yet another one.
I'd like to apologize to those whose comments and questions I might have
neglected to reply to during past discussions. I've needed to
concentrate on my studies for the past week or two, and have had little
energy to spend here. So if anyone has something to say, please do.
Here's a rough sketch of what I think should be done in what order. A
lot of the stuff that came up during the discussions here is missing,
and that's how it should be. This list is supposed to end up being
actually doable and realistic. Remember the magic words: "For starters."
1) Switch to using the JACK D-Bus interface for lashd<->jackd communication.
2) Add a D-Bus control interface to LASH, which is supposed to
eventually replace the current liblash server interface API.
3) Change the liblash client interface's internals to use D-Bus for
communication with lashd.
4) Start serious work on re-planning the API (extending it or adding an
alternative one) and implementing new features. Most of the things
discussed so far will fall under this category, and many of the
suggested feature improvements will also affect API design. When this
stage begins we should have another look at what's been said so far, and
what we can make out of it.
I'd like to add that although this is more or less what I'll be putting
in my Summercode application, things probably will, and by all means
should, also evolve on their own weight. Some of the changes I listed
may already be written before June; who knows, maybe we'll have sharks
with lasers. And my application may not be chosen at all, but that
should only matter in terms of available resources to LASH development.
Thanks,
Juuso
Bob Ham wrote:
> In case you missed this.
Sorry that this took me so long!
> On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote:
>> On Friday 25 January 2008 18:27:10 Bob Ham wrote:
>>> On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote:
>>>> On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
>
>> And I can imagine how the session loading could happen approximately like
>> this:
>> - LASH launches the JACK controller app,
>> - the JACK controller app modifies JACK settings and possibly restarts JACK if
>> necessary,
>> - LASH launches the rest of the clients,
>> - LASH connects the ports between the clients.
>
>> Now imagine the above scenario, but imagine that the JACK controller app
>> doesn't get launched first. It will potentially wreck the session if it
>> restarts JACK after other clients have loaded. If controlling JACK settings
>> is done by one of the session clients, should that client be able to register
>> to LASH with a special flag which indicates that it should launch first?
>
> This would be dealt with by client priorities (or dependencies.)
What would guarantee that a JACK controller app would always get first
priority (or be a "root dependency")? The controller app itself via an
init flag? The user (bad idea IMHO)?
Anyway I'm not sure if this topic is going anywhere in the foreseeable
future. I fully agree that priorities/dependencies is a good idea, though.
>>>>> User interface standard
>>> Promote a standard to LASH clients in order to present a consistent user
>>> interface. This would be like the GNOME HIG but audio-specific, eg,
>>> specifying knob widget appearance and behaviour, recommending audio
>>> widget toolkits, etc.
>> You're treading on flammable ground here. I wouldn't want LASH to have the
>> slightest authority over what toolkits and/or widgets the clients are coded
>> with. And I don't see any reason why LASH should even care; LASH isn't a
>> plugin host. I should be able to include an Ncurses-based drum machine with
>> my session if I please.
>
> The GNOME HIG isn't enforced. Nor, I believe, is there any way to
> enforce it. It's simply a document to communicate to developers of
> GNOME applications the expectations that any application has on it when
> taking part in a GNOME desktop.
>
> Similarly, the user interface standard for LASH would simply be a
> document to communicate to developers of LASH clients the expectations,
> in terms of user interface harmony, that any client has on it when
> taking part in a LASH session.
I didn't realize you meant a recommendation and not some UI protocol.
(I'm not too familiar with GNOME.) Sure, but why should it be
LASH-centric? Why not write an official linuxaudio.org HIG?
Another question is how needed/desired something like this actually is.
(Does the VST SDK come with a HIG document?)
>>>>> Automatic client installation
>>>> This sounds an awful lot like stepping on the toes of packagers and
>>>> package managers. Unless you mean something completely different, of
>>>> course.
>>> What's meant is: if you load a session and it includes a client that
>>> isn't installed on the system, then make it such that it is installed
>>> and the session can be loaded. This is no small thing. There are a few
>>> options:
>>>
>>> 1. Create a system which abstracts package management for different
>>> distros
>>> 2. Try and create an automatic compilation environment, similar to
>>> ports on Freebsd or portage on Gentoo (lol)
>>> 3. Use autopackage
>>>
>>> From the client side, this would be very simple: the programmer just
>>> provides a URL to some meta-information that describes the packages
>>> needed for that LASH client. I think this is pretty doable now that
>>> number 3 exists.
>> Yes, you are stepping on packagers' toes here -- heavily.
>
> Why do you think packagers' toes are being stepped on? I can't see any
> conflict between package developers and a LASH package installer.
If we are to restrict this topic to strictly providing hooks for
existing package managers, then we might be able to stay out of trouble.
Otherwise I suggest you go ask about it on #debian. :)
>> Abstracting package management for distros is an insanely huge task
>
> Note the phrase "this is no small thing" above.
>
>> , and not
>> likely to work in practice.
>
> Possibly
>
>> Creating an automatic compilation environment --
>> well, I assume you're joking
>
> Nope
>
>> because this would equal writing your own
>> source-based package manager
>
> Yep
All I have to say is good luck. :)
>> Using autopackage is out of the question,
>> because you simply can't fulfill the needs of all distros
>
> Autopackage exists. It works. It doesn't seem to be out of the
> question. The issue isn't fulfilling the needs of the distro but
> fulfilling the needs of the user.
The point isn't to safeguard the poor packagers from grey hair, although
to a certain extent that's also a factor. What I'm worried about is how
on earth will a rogue package manager, working irrespective of the
distro's own managing system, benefit the users in the long run?
Sure, you will be able to quickly install externally provided packages
via some nifty tool, just like you can quickly unpack binary tarballs in
your root. And when the distro's package manager pulls a straw up its
nose due to broken lib dependencies and whatnot, I guess the users won't
feel too good afterall.
>> If a session manager would take on package management like this -- which it
>> definitely _shouldn't_ in the first place
>
> Why not?
I apologize if this sounds like circular logic, but it is: A package
manager is what you use for managing packages, and when managing
packages what you should use is a package manager. Linux != Windows.
>> -- it would have to work absolutely
>> _perfectly_ on _all_ possible distros. Either that, or nothing.
>
> Why would reverting to normal, not-as-astonishingly-cool behaviour on
> some distros be bad?
An external package installation system would by and far not work
"normally" at all on many systems.
>> I wouldn't want autopackage messing around with my box -- I want
>> packages installed the way they normally are with Source Mage.
>
> Then don't use the automatic LASH client installer :-) Or you could
> implement the distro-specific functionality for your distro. That would
> allow you to have your packages installed the way they normally are with
> Source Mage.
That's as far as I'd be prepared to go. If LASH would notice that I
didn't have $PROGRAM installed, and it would tell me my distro's package
name for $PROGRAM, I'd be very happy. I would _possibly_ even be willing
to click on a link saying, "Click here to install $PROGRAM using
$YOUR_PACKAGE_MANAGER".
And even that "simple" feature would require LASH to ship with an
up-to-date matrix of program names matched against all distros'
corresponding package names...
>> Considering how you've been defending LASH from features that you deem outside
>> of its domain, I'm surprised that you would come up with this idea.
>
> Session loading is within the domain of LASH.
I would strongly argue that managing packages is way beyond the concept
of session loading. But I don't feel that we should really be wasting
much time on this subject at this point anymore.
>>>>> Redesign client/server communication
>>>>> Certificate based security/encryption
>>>> Why would managing an audio session demand that the connections be
>>>> certified and encrypted? Unless you're thinking network-wise (i.e.
>>>> sessions that span several networked computers).
>>> I'm thinking network-wise.
>> As I've said before, I don't believe it's a good idea to add this stuff to the
>> client protocol. Inter-host communication is a different thing.
>
> There's an assumption here that lashd<->lashd and lashd<->client
> protocols aren't the same thing. They would be communicating very
> similar information. Having two protocols would be unwieldy.
Can you clarify whether you mean the LASH client or server interface
when you say that they would communicate similar information?
Juuso
Salve,
Is there anything like pmidi for midi-over-jack
(i.e. a command line midi file player) ?
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
i was following the discussion on technical details.. it was
interesting and i learnt a few things.. still not enough to put it
into any code..
i sort of sorted out what is the jack-midi about but was trying to
play a bit stupid (sometimes i can't stop that game even when i want
;)) and fnd something on mailing list or web site... couldn't find
it.. these would be the questions:
what would be the benefits of using jack-midi over alsa sequencer?
is that related to jack transport somehow? how?
is that better timing? why?
is that better integration/sync with some other jack events related to
time? which events?
it would be great if answers are not just 'yes' ;) but i'm not really
looking for more than one sentence for any question... i can then
format it into something which then could be put on the web site...
hope this is not too much of wasting time of developers...
thanx
