Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7535 discussions

[LAD] Cracking sound via USB (ALSA urb.c:480: frame 5 active: -18)

by Aurélien Leblond

Hi, I seem to have an issue with USB soundcards on my laptop. I have tried two of them, but I keep getting crackling sounds while playing with Ardour or Hydrogen. Everytime this crackling sounds occur, I get the following in dmesg: ALSA urb.c:480: frame 5 active: -18 The Kernel is 2.6.39 with Irqthreads, Alsa is the git version (1.0.24). I have tried a lot of things already, but I'm really ready to restart the investigation from scratch and to provide any information! Thanks in advance for the help. dmesg details: [ 41.927872] CE: hpet2 increased min_delta_ns to 7500 nsec [ 41.927897] CE: hpet2 increased min_delta_ns to 11250 nsec [ 75.569991] CE: hpet5 increased min_delta_ns to 7500 nsec [ 75.570003] CE: hpet5 increased min_delta_ns to 11250 nsec [ 79.234811] ALSA urb.c:480: frame 1 active: -71 [ 102.065990] CE: hpet4 increased min_delta_ns to 7500 nsec [ 102.066005] CE: hpet4 increased min_delta_ns to 11250 nsec [ 147.964992] ALSA urb.c:480: frame 5 active: -18 [ 185.833311] ALSA urb.c:480: frame 4 active: -18 [ 271.091937] ALSA urb.c:480: frame 1 active: -18 [ 276.686711] ALSA urb.c:480: frame 1 active: -18 [ 300.120588] ALSA urb.c:480: frame 0 active: -18 [ 302.416319] CE: hpet increased min_delta_ns to 30169 nsec [ 318.225546] ALSA urb.c:480: frame 7 active: -18 [ 318.433469] ALSA urb.c:480: frame 7 active: -18 lsusb -v gives (only the details about the soundcard): Bus 001 Device 003: ID 0763:2080 Midiman M-Audio RunTime DFU Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0763 Midiman idProduct 0x2080 M-Audio RunTime DFU bcdDevice 1.51 iManufacturer 1 M-Audio iProduct 2 Fast Track Ultra iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 340 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 5 bFunctionClass 255 Vendor Specific Class bFunctionSubClass 1 bFunctionProtocol 0 iFunction 2 Fast Track Ultra Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 2 Fast Track Ultra ** UNRECOGNIZED: 0b 24 01 00 01 34 00 03 01 02 03 ** UNRECOGNIZED: 0c 24 02 01 03 06 00 08 03 00 00 00 ** UNRECOGNIZED: 09 24 03 02 01 01 00 01 00 ** UNRECOGNIZED: 0c 24 02 03 01 01 00 08 03 00 00 00 ** UNRECOGNIZED: 09 24 03 04 03 06 00 03 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 03 01 01 00 ** UNRECOGNIZED: 14 24 02 01 08 03 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0138 1x 312 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 1 Transfer Type Isochronous Synch Type None Usage Type Data wMaxPacketSize 0x0003 1x 3 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 02 01 01 00 ** UNRECOGNIZED: 14 24 02 01 08 03 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0138 1x 312 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 02 01 01 00 ** UNRECOGNIZED: 14 24 02 01 08 03 18 04 44 ac 00 80 bb 00 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0138 1x 312 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 3 MIDI Streaming bInterfaceProtocol 0 iInterface 5 Fast Track Ultra MIDIStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 63 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 1 Embedded bJackID 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 2 External bJackID 2 iJack 0 MIDIStreaming Interface Descriptor: bLength 8 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) Warning: Descriptor too short bJackType 1 Embedded bJackID 3 bNrInputPins 1 baSourceID( 0) 2 BaSourcePin( 0) 1 iJack 8 MIDIStreaming Interface Descriptor: bLength 8 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) Warning: Descriptor too short bJackType 2 External bJackID 4 bNrInputPins 1 baSourceID( 0) 1 BaSourcePin( 0) 1 iJack 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 8 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 3 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 254 Application Specific Interface bInterfaceSubClass 1 Device Firmware Update bInterfaceProtocol 0 iInterface 7 M-Audio DFU Device Firmware Upgrade Interface Descriptor: bLength 9 bDescriptorType 33 bmAttributes 1 Will Not Detach Manifestation Intolerant Upload Unsupported Download Supported wDetachTimeout 2000 milliseconds wTransferSize 1024 bytes bcdDFUVersion 1.10 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0001 Self Powered

14 years, 8 months

Re: [LAD] RME FIREFACE 400? RME MULTIFACE II?

by Ralf

On Mon, 2011-05-23 at 14:09 -0600, Gustin Johnson wrote: > On Sun, May 22, 2011 at 9:43 PM, Ralf <ralf.mardorf(a)alice-dsl.net> wrote: > > On Sun, 2011-05-22 at 13:23 -0600, Gustin Johnson wrote: > >> I would stay away from the Fireface and the multiface (unless you > >> connect the multiface to another interface). > >> > >> FWIW, I have a 9652 PCI card and an RME ADI 8-DS. If I need more > >> channels there is an Alesis ADAT that I can connect to it, albeit at > >> only 16/48. It is important to note that the 9652/9652 do not have > >> any ADC/DACs on them and rely on outboard gear for that. > >> > >> This particular rig has been solid and stable for years and has been > >> in 3 different rigs, the latest being an Intel Sandy bridge. If you > >> can afford it I highly recommend the RME PCI and PCIe solutions. > >> Their Firewire solutions have traditionally been the exact opposite > >> under Linux. > > > > Hm? I tries to switch from LAD to LAU, regarding to current user > > queries, but it failed. Hi Admin [1] ;). > > > > Hi Gustin :), hi Ubuntu Studio users list :), pardon LAD ;) > > > > IIUC a HDSPe AIO or DSP 9632 is all I need, if I just need a stereo IO? > > I only need to buy a BF-BOXLRMKH or BF-BOCMKH breakout cable? > > There are a number of possible solutions. It sounds like the AIO > might be what you want, but I would ask someone local if you are > unsure (in other words, don't just take my word for it). I did send a request to my dealer. At the moment I tend to buy a 9632 and if I should switch the mobo one day, I perhaps have to replace it by the AIO, anyway, the 9632 is less expensive. But I'm undecided. > > > > If I need additional IOs and wish to avoid Multiface firmware issues, I > > can add AI4S-192 AIO and AO4S-192 AIO. > > > You could add anything that speaks ADAT, assuming you get the PCI/PCIe > card with ADAT connectors on it. > > > If I need much more IOs and don't have enough money for RME IOs, I can > > e.g. use a BEHRINGER ADA8000 ULTRAGAIN PRO8 DIGITAL by ADAT connection. > > The sound quality might be less good and I guess this will add extra > > latency and Ardour won't auto-compensate this extra latency > > automatically? > > > What latency are you talking about? The only latency this adds is > electrical switching and media conversion + travel time for the > optical signal + the DAC/ADC. The sound quality of Behringer tends to > be lower than other solutions, but this should work. I guess I'll start with just AI4S-192 AIO and AO4S-192 AIO for home recording. If I should need more channels I'll order a cheap ADAT device at another time. More channels might be needed to do rehearsal room recordings, with cheap microphones, hence the sound quality is less important, "live" music has an advantage regarding to the feeling compared with home recording, just for home recording I wish to get the most near professional sound that is possible by my equipment, but at home I don't need much channels. 2 for the stereo sum and some to loop in a 19" reverb or to record drum sounds from a drum module by separated channels at the same time. > > > As long as I'm using a mobo with PCI slots I can use AI4S-192 AIO and > > AO4S-192 AIO with a DSP 9632 and when I switch to a mobo with PCIe only > > I can switch from DSP 9632 to HDSPe AIO and keep AI4S-192 AIO and > > AO4S-192 AIO (and e.g. a BEHRINGER ADA8000 ULTRAGAIN PRO8 DIGITAL ;)? > > This sounds right. If in doubt check with RME. The compatibility of > the add on boards is listed on this page: > http://www.rme-audio.de/en_products_hdsp_expansion_boards.php > > > > Using a DSP 9632 with a PCIe to PCI bridge doesn't work or at least > > could cause issues? > > > Never heard of such a thing. I would not trust it, but I tend to be > skeptical of such kludges. Me too. Thank you, Ralf

14 years, 8 months

Re: [LAD] Looping audio to oneself via Jack

by Stéphane Letz

> >> I can't tell you about jack API stuff that might be relevant but I can >> tell you that it usually works, there's nothing in jack that forbids it. >> There's one thing though you should be aware of: the output will reach >> the input one processing cycle after the output was produced, hence it >> will be delayed. This is simply a consequence of how jack works. > > This may be a long standing bug that has been reported before. > The jack authors seem to see it as a 'feature'. > > The summing of signals connected to an input port is done when > that port's owner calls jack_port_get_buffer(). There is an > optimisation: when there is only one output connected, you > just get a copy of its buffer pointer, the sample data is not > copied to separate input buffer. > > Now if (1) you make a loopback AND (2) your app clears its > output buffers at the start of the cycle AND (3) it does > this before calling jack_port_get_buffer() on its inputs, > then the looped back output will appear to be empty. > > A workaround would be to ensure condition (3) is not true, > i.e. call jack_port_get_buffer() on inputs before clearing > your ouputs. > > But even that won't work if there is just one output connected > to the loopback input: the optimisation means its data is not > copied and you will see an empy buffer anyway. > > IMHO Jack should make a copy of an output buffer if it is > looped back even if that would otherwise not be necessary. > > Not doing this violates assumptions that are (IMHO) very > legitimately made by all authors: either that > > (1, strong form) input buffers do not change during a > process callback, or > (2, weaker form) they do not change after the call to > jack_port_get_buffer(). > > Ciao, > > -- > FA > > The issue has (hopefully) been fixed in jack2 since a while, Fons have you ever tested? Thanks. Stéphane

14 years, 8 months

Re: [LAD] RME FIREFACE 400? RME MULTIFACE II?

by Ralf

On Sun, 2011-05-22 at 13:23 -0600, Gustin Johnson wrote: > I would stay away from the Fireface and the multiface (unless you > connect the multiface to another interface). > > FWIW, I have a 9652 PCI card and an RME ADI 8-DS. If I need more > channels there is an Alesis ADAT that I can connect to it, albeit at > only 16/48. It is important to note that the 9652/9652 do not have > any ADC/DACs on them and rely on outboard gear for that. > > This particular rig has been solid and stable for years and has been > in 3 different rigs, the latest being an Intel Sandy bridge. If you > can afford it I highly recommend the RME PCI and PCIe solutions. > Their Firewire solutions have traditionally been the exact opposite > under Linux. Hm? I tries to switch from LAD to LAU, regarding to current user queries, but it failed. Hi Admin [1] ;). Hi Gustin :), hi Ubuntu Studio users list :), pardon LAD ;) IIUC a HDSPe AIO or DSP 9632 is all I need, if I just need a stereo IO? I only need to buy a BF-BOXLRMKH or BF-BOCMKH breakout cable? If I need additional IOs and wish to avoid Multiface firmware issues, I can add AI4S-192 AIO and AO4S-192 AIO. If I need much more IOs and don't have enough money for RME IOs, I can e.g. use a BEHRINGER ADA8000 ULTRAGAIN PRO8 DIGITAL by ADAT connection. The sound quality might be less good and I guess this will add extra latency and Ardour won't auto-compensate this extra latency automatically? As long as I'm using a mobo with PCI slots I can use AI4S-192 AIO and AO4S-192 AIO with a DSP 9632 and when I switch to a mobo with PCIe only I can switch from DSP 9632 to HDSPe AIO and keep AI4S-192 AIO and AO4S-192 AIO (and e.g. a BEHRINGER ADA8000 ULTRAGAIN PRO8 DIGITAL ;)? Using a DSP 9632 with a PCIe to PCI bridge doesn't work or at least could cause issues? Best, Ralf [1] -------- Forwarded Message -------- From: Ralf <ralf.mardorf(a)alice-dsl.net> To: linux-audio-user-owner(a)lists.linuxaudio.org Subject: Subscription failed Date: Mon, 23 May 2011 04:40:52 +0200 Hi, I want to switch from LAD to LAU, regarding to some user queries about sound cards. When I first tried to subscribe, I made a typo for my email address, then I tried again without typo, but it failed several times, without any error messages. Best, Ralf

14 years, 8 months

Re: [LAD] RME FIREFACE 400? RME MULTIFACE II?

by Jonathan Woithe

> On 05/22/2011 11:43 AM, Ralf wrote: > > Hi :) > > > > I only watched pictures and read texts but didn't hear one of those RME > > devices, anyway, until now I tend to order the RME FIREFACE 400 or RME > > MULTIFACE II if they shouldn't cause issues with Linux. The two HDSP be > > possible too. > > > > Any experiences, information? Jorn wrote: > the fireface is an ieee1394 device, and the ffado drivers are somewhat > experimental. so yes, this would be an "issue with linux". i suggest you > check the ffado.org website and look through the ffado mailing list > archive to see if the current level of support is sufficient for what > you want to do. [ Disclaimer: I am working on the ffado FF400 driver ] The ffado support for the RME devices is indeed experimental. If you're interested, head across to www.ffado.org and browse the device support pages for the latest information. In short, the latest ffado svn revision contains a driver which should be capable of getting audio into and out of a FF400 (the FF800 will follow once the FF400 has bedded down). Some device controls are also available via ffado-mixer (filling in the rest is mostly a boilerplate coding exercise which I'll do once audio has stabilised). I am continuing testing myself but early adopters (those who already have a ff400 in most cases) are encouraged to try the driver on their own systems to provide feedback to me about how the driver performs on a variety of platforms. To summarise: support for the RME Fireface 400 under ffado is moving in the right direction and is ready for interested people to test, but I would not be saying that it's ready for prime time yet. Having said that, I think the bulk of the work is now done and I want to move on this as quickly as real life permits. :-) Regards jonathan

14 years, 8 months

Re: [LAD] What sound cards are recommender by developers? I'll order next week!!!

by Machel Sylvain

Hello Ralf, Have you already envisaged to use Digigram boards like the vx222 one with alsa driver. Regards, Sylvain ======================================== Message du : 21/05/2011 De : "Ricardo Wurmus " <ricardo.wurmus(a)gmail.com> A : "Ralf" <ralf.mardorf(a)alice-dsl.net> Copie à : linux-audio-dev(a)lists.linuxaudio.org Sujet : Re: [LAD] What sound cards are recommender by developers? I'll order next week!!! If you cannot keep your Envy24 card for MIDI I/O, you might want to check out the ESI MIDIMATE II. It's a minimal USB MIDI interface (it's really just a cable, no box) which works very well in my setup. This could open up a few more alternatives for you, in case you decide on a device that would require you to remove the Envy24 card. On 21 May 2011 20:37, Ralf wrote: > Pardon that I ask this on the developers list, but it seems to be the > best place regarding to the information about hardware, that is or isn't > well supported for or by Linux. > > I'm flirting with the idea of buying a RME PCI card or firewire device > or if recommended a card from another vendor. The device should have > around 4 analog IOs, for MIDI I could keep one of my Envy24 cards, as > long as a new device only needs one PCI slot. I guess PCI is less > problematic than firewire? > > I'll order next week. > > It's important that the analog IOs and converters etc. keep the sound > without audible loss, similar to consumer equipment, that is not the > most worse. Professional sound quality isn't needed, but my TerraTec EWX > 24/96 or similar Envy24 cards and all those onboard devices I ever > heard, don't reach good consumer quality, they produce marked loss for > the sound quality. > > I could spend 800,- EUR or less ;). > > Any recommendations for sound cards? > > I already got some recommendations and until now this one seems to be > the most confidence inspiring device ... just a feeling ;): > http://www.thomann.de/gb/rme_digi_9632_hdsp_pcikarte.htm > > OTOH, I'm doubtful, regarding to the costs. I thought that new devices > are more expensive. > > Somebody else recommended this one: > > http://www.thomann.de/gb/focusrite_saffire_pro_40.htm > > I can't ask friend, because they won't care about compatibility to > Linux :(, I guess that e.g. Motu isn't (well) supported. > > Before I order a sound device, I'll ask if I could test it, when > ordering at Thomann or a similar dealer. The problem is that I have to > order, because AFAIK there are no good music stores near to my hometown > Oberhausen/Rheinland, that are easily reachable by public transit, > dunno, perhaps Kurt Spiecker + Dirk Pulch are still ok. > > Best, > > Ralf > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

14 years, 8 months

[LAD] RME FIREFACE 400? RME MULTIFACE II?

by Ralf

Hi :) I only watched pictures and read texts but didn't hear one of those RME devices, anyway, until now I tend to order the RME FIREFACE 400 or RME MULTIFACE II if they shouldn't cause issues with Linux. The two HDSP be possible too. Any experiences, information? RME FIREFACE 400 http://www.thomann.de/gb/rme_fireface_400.htm RME MULTIFACE II http://www.thomann.de/gb/rme_multiface_ii.htm RME HDSP 9652 http://www.thomann.de/gb/rme_digi_9652_hdsp.htm http://www.thomann.de/gb/rme_9652_hdsp_retour.htm RME HDSP 9632 http://www.thomann.de/gb/rme_digi_9632_hdsp_pcikarte.htm The sound quality at least should reach that of my elCheapo consumer DAT Sony DTC-670. The Terratec EWX 24/96 does hardly reach the sound quality of my Yamaha MT44D 4 track analog cassette recorder, when it wasn't broken, but well maintained and I heard several Envy24 cards that hardly reach the 4 track recorders quality. I'm not interested in this one, but the price-performance ratio is amazing: BEHRINGER XENYX X2442 USB http://www.thomann.de/gb/behringer_xenyx_x2442_usb.htm I've got a Behringer EURORACK UB2442FX-PRO a very bad mixer, hard to clean, hard to use, because everything is small, even if it's dust protected, after 3 years dust issues started. All faders are still ok, but Group buttons are completely out of order, some channels don't work any more. I don't had enough money to get a better mixer, when my old get completely broken but OTOH, the sound quality anyhow is good enough to reach good consumer quality that is better, than what my Terratec EWX 24/96 are able to record. I wish to get a good sound card, but this Behringer might be interesting for some people. Note, I never compared a Mackie with the UB2442FX-PRO directly, a friend has got nearly the same mixer from Mackie, and I've got the impression that the sound quality of the Mackie is better. IMO Mackie is some kind of reference for low cost home recording equipment. Things should sound similar to a Mackie or better. I'll start reading http://www.google.de/#sclient=psy&hl=de&source=hp&q=RME+FIREFACE+400 +linux&aq=f&aqi=&aql=&oq=&pbx=1&bav=on.2,or.r_gc.r_pw.&fp=5a4a001e44ffdadc now. Best, Ralf

14 years, 8 months

[LAD] LAC 2011 pictures

by Marc Groenewegen

Hi all, here are some pictures of the LAC 2011 and because I had an extra day to get around Maynooth, the university (NUIM) and beyond, there are some non-LAC pictures as well. Frank will probably put more pictures on the LAC-2011 website but in the meantime this already gives you an impression: http://www.flickr.com/photos/marcdinkum/sets Feel free to add comments. Cheers, Marc

14 years, 9 months

[LAD] [HEADSUP] Please submit something for the Audio track at LPC!

by Lennart Poettering

Heya, The Linux Plumbers Conference 2011 is coming soon. Mark Brown and I are running the Audio track at LPC, and we are looking for more proposals! So, please consider submitting something if you haven't done so yet. We are looking for all kinds of technical talks covering everything audio plumbing related: audio drivers, audio APIs, sound servers, pro audio, consumer audio. If you can propose something audio related -- like talks on media controller routing, on audio for ASOC/Embedded, submit something! If you care for low-latency audio, submit something. If you care about the Linux audio stack in general, submit something. LPC is probably the most relevant technical conference on the general Linux platform, so be sure that if you want your project, your work, your ideas to be heard then this is the right forum for everything related to the Linux stack. And the Audio track covers everything in our Audio Stack, regardless whether it is pro or consumer audio. So, submit! submit! submit! (And contrary to what the web site might suggest regarding deadlines we'll still consider your submission, if you post it quickly!) http://www.linuxplumbersconf.org/2011/ Lennart -- Lennart Poettering - Red Hat, Inc.

14 years, 9 months

[LAD] AVB applications

by Duncan Gray

This is to bring a discussion from the Jack Dev list to this more appropriate forum as suggested by Arnold Krille. First, I hear lots of people seemingly thinking that AVB (IEEE 1722) and the IEEE 1588 version of Precision Timing Protocol can be done in the kernel. It cannot and it must not. They both need hardware assist. Period. A timestamp is specified to be inserted based on the leading edge of the header immediately after the preamble. If anyone ever makes some neighboring equipment that has done these with the required precision, then you will kill that clock network and there will be yet another good reason not to bring Linux to the workplace. The ONLY exception is that if the listener is a stream-to-disk system, then the timestamp system can simply be ignored. Such a listener will never turn on PTP, but that won't hurt, because it will just ask for the 1722 stream and the talker will spit it out without knowing that that node doesn't play PTP. The version of PTP that is used in AVB is from the 802.1AS specification. The acronym PTP is now an ambiguous one that has at least these two uses, and I have heard some other hardware-assisted networked timing schemes called PTP. IEEE 1588 specifies an epoch-based struct with 48 bits of seconds (This gives 8.9 million years before a "y2k" hits IEEE 1588) and a 32-bit number that specifies nano-seconds. the 802.1AS sub-spec also uses this epoch-based timestamp. PTP maintains one suite of transactions to keep itself timed. This is blind to AVB. AVB creates Word Clock timeframes using the PTP wall-clock that MUST be made available to the 1722 layer. IF YOU HAVE PTP, then you can synthesize predictive wallclocks using a buffer-full scheme in a PTP-capable NIC. That NIC has to be configured to pay out the frames per the 802.1Qav forwarding and scheduling spec. This is how streamers will deliver streams that are well-timed, low-jitter streams. There are fruit companies doing this as we speak with new NICs that have been enabled from Broadcom and Marvell (and any host of others.) It is possible to fake a GrandMaster clock using kernel-timed calculations. The Best Master Clock Algorithm (BMCA) of a two-node system will be forced to accept such a sloppy clock and the slave will achieve lock, but with jitter that will fail a normally specified PTP system. Noisy environment listeners will not hear this, but clean listening will reveal the various artifacts of such jitter. You can just make a leaky-bucket PLL at a receiver and use the DPLL frequency to inform SRC. This hack will be un-noticed by the average media-player person, but not by the critical listener. When the 1722 timestamp is constructed, it is a complex assembly from the 802.1AS timestamp. The 802.1AS timestamp is a two-part thing, as specified above with its first part being simply seconds. This will not roll over in the lifetime of Linux, our species or even our continents, let alone a recording session. The second part is specified to roll over at decimal one billion-1 = 999999999 = 0x 3B9ACBFF. The timestamp in IEEE 1722 rolls over at unsigned long = 4294967295 = 0xFFFFFFFF, which is 4.294967296 seconds. I apologize for quoting "weeks between rollover" in the previous thread. IEEE 1588 and IEEE 1722 are Ethernet-Only protocols, do not shoe-horn them into IP. I have heard lots of people say that AVB is just some thing for consumers. go to http://grouper.ieee.org/groups/1722/ and hover over some of the names to find where they work. It was, in fact, designed FIRST to very easily accommodate Pro Audio: Reliability. Multiple-Node Synchronization without the need for Sample Rate Conversion. Low-Jitter. Unlimited (at least not limited by the protocol, only the bandwidth) channel count. And then it would be a trivial subset to get two - or 5.1, 7.1 any surround count - channels to go from my CD player to any media player over some LAN. (However, as of two autumns ago, they were still kvetching over Wi-Fi.) Finally, Yes, the CLOCK_REALTIME can be very simply pasted from a good PTP instance.

14 years, 9 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev