The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Lynx vs RME - sick of the never ending Lynx beta test? i was. Audio Interfaces
Old 27th March 2010
  #1
Lives for gear
 
thedigitalgod's Avatar
 

Lynx vs RME - sick of the never ending Lynx beta test? i was.

ive been a lynx user for years, but i became very sick of the never ending driver beta test (although the drivers are supposed to have been final versions, and are stated to be and named as such).

so i decided to get an RME HDSPe AES to replace my Lynx AES16e. ROCK SOLID STABLE! i tested the latency of each card under the same conditions on the same system to see what i was giving up in terms of speed for reliability, especially since the Lynx is said to be faster. below are the results of the test in case anyone finds it useful:

- test done at 88.2/24
- the "reaper" column is the latency reported by reaper
- the "RME" and "Lynx" columns are the latency reported by each in their own settings interface
- "samples" is the result of a ping from out to in via reainsert
- "ms" is simply samples/(88,200/1000) to give the latency in milliseconds

RME
buffer.....samples........ms.......reaper.........RME
32..........280............3.17......0.3/1.1........0.7
64..........344............3.90......0.7/1.4........1.5
128........472............5.35......1.4/2.2.........3
256........728............8.25......2.9/3.6.........6
512........1240..........14.05.....5.8/6.5.........12
1024.......2264..........25.66....11/12............23
*2048....*4312........*48.88....*23/23........*46
*4096....*8408........*95.32....*46/47........*93

Lynx
buffer.....samples........ms.......reaper......... Lynx
32..........215.............2.43.....0.7/0.3.........0.36
64..........279.............3.16.....1.4/0.7.........0.72
128........471..............5.34.....2.1/1.4........1.45
256........727..............8.24.....3.6/2.9........2.9
512........1239............14.04....5.4/5.8........5.8
1024.......2263............25.65...12/11..........11.6

*Lynx does not provide these settings

multiple tests provided for +/-2 samples at each buffer setting

EDIT--the formatting went all to hell when it posted, its a little better now, but a more easily readable file is attached
Attached Files
File Type: zip latency test.zip (647 Bytes, 34 views)
Old 27th March 2010
  #2
Lives for gear
 
fossaree's Avatar
I don't get it , because LYNX aes 16e are doing better regarding spec. ...
could you elaborate more?
Old 27th March 2010
  #3
Lives for gear
 

good info...they both seem fast...however in my experience running heavy sessions in 64 or 32 isn't realistic after a while and in the end it comes down to which has the more useful virtual mixer for headphones....and it seems that the RME wins hands down there...also I like the BNC word in/out feature...nice choice if you prefer clock via BNC as opposed to AES.... also clocking from external source (say Big Ben) means you can clock the card directly and not just via the converter...there is a difference IMHO

I think I'm gonna get me one...right now!
Old 27th March 2010
  #4
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by fossaree View Post
I don't get it , because LYNX aes 16e are doing better regarding spec. ...
could you elaborate more?
yeah, but like was said in the other thread, the lynx just isnt reliable. my point was to see how much slower the RME was going to be, and the answer turned out to be not much at all in exchange for a reliable system that works -- which is a nice change
Old 27th March 2010
  #5
Lives for gear
 
fossaree's Avatar
Hmm , now I get it !

Anyways , I hope I don't have any issue regarding stability with my mac pro and logic !!!

Fingers crossed ;-)
Old 27th March 2010
  #6
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by glissando View Post
good info...they both seem fast...however in my experience running heavy sessions in 64 or 32 isn't realistic after a while and in the end it comes down to which has the more useful virtual mixer for headphones....and it seems that the RME wins hands down there...also I like the BNC word in/out feature...nice choice if you prefer clock via BNC as opposed to AES.... also clocking from external source (say Big Ben) means you can clock the card directly and not just via the converter...there is a difference IMHO

I think I'm gonna get me one...right now!
not that i suggest you get the Lynx over the RME, but the Lynx can clock via BNC, its provided as part of the mini d-sub pinout, the cable just has to be made with the BNC dongle
Old 27th March 2010
  #7
Lives for gear
 
fossaree's Avatar
Quote:
Originally Posted by thedigitalgod View Post
yeah, but like was said in the other thread, the lynx just isnt reliable. my point was to see how much slower the RME was going to be, and the answer turned out to be not much at all in exchange for a reliable system that works -- which is a nice change
as matter of fact I was wondering that this test shows that this kind of setup (either lynx or rme pciE) rivals PTHD...
Old 27th March 2010
  #8
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by fossaree View Post
as matter of fact I was wondering that this test shows that this kind of setup (either lynx or rme pciE) rivals PTHD...
absolutely. with the ability to run >100 tracks with hundreds of plugs (last test was 150 SSL stereo Channel Strips at 256 buffer) its a no brainer
Old 27th March 2010
  #9
Lives for gear
 

Quote:
Originally Posted by fossaree View Post
as matter of fact I was wondering that this test shows that this kind of setup (either lynx or rme pciE) rivals PTHD...
You have to be careful of assuming that IMO...I don't like PT, but at this point I think it has an edge in the latency department...simply because running sessions at 64 or 32 buffer is unrealistic after some heavy editing...which is par for the course these days...and using a virtual mixer like total mix is useful, but it is still an extra step that can get convoluted...

That being said, I have no problem working at 128 or using a virtual mixer for near zero latency...I can make a record just fine with that, just as long as the system and the card are firing on all cylinders...hopefully the aurora will provide me with that.
Old 28th March 2010
  #10
Lives for gear
 
fossaree's Avatar
Quote:
Originally Posted by glissando View Post
You have to be careful of assuming that IMO...I don't like PT, but at this point I think it has an edge in the latency department...simply because running sessions at 64 or 32 buffer is unrealistic after some heavy editing...which is par for the course these days...and using a virtual mixer like total mix is useful, but it is still an extra step that can get convoluted...

That being said, I have no problem working at 128 or using a virtual mixer for near zero latency...I can make a record just fine with that, just as long as the system and the card are firing on all cylinders...hopefully the aurora will provide me with that.
well , but you can easily track @ 32 , and mix @ 128 ...
Old 28th March 2010
  #11
Lives for gear
 

Quote:
Originally Posted by fossaree View Post
well , but you can easily track @ 32 , and mix @ 128 ...
Yeah that's true...let us know how your card works out
Old 28th March 2010
  #12
Lives for gear
 
fossaree's Avatar
Quote:
Originally Posted by glissando View Post
Yeah that's true...let us know how your card works out
Thanks ! I'm already scanning LYNX's forum
Old 28th March 2010
  #13
Lives for gear
 

Question

Quote:
Originally Posted by thedigitalgod View Post
yeah, but like was said in the other thread, the lynx just isnt reliable. my point was to see how much slower the RME was going to be, and the answer turned out to be not much at all in exchange for a reliable system that works -- which is a nice change
What OS do you have? x32 or x64?
what motherboard ?
what CPU ?
Sharing IRQs ?

my Lynx AES16 works great, if i select 16-Bit colors in the video card, because its sharing IRQs.
newer X58 motherboards cannot select IRQs manually.
with the older board with 975 chips like Asus P5W DH Deluxe, was not sharing IRQs, was a dream.

Windows XP MCE 32-Bits, 3GB Ram.

the only true problems are>
ext.clock not always locks, shows that locks, but does not change, i have to change a few times to work. it sounds 1 second of digital garbage when locks, if does not locks, does not sound the clock change.
DDS cards like RME or Motu traveler clock change garbage does not sound.

SynchroLock(TM) dissabled, because i have better clocks, must be dissabled.

the other problem is, if the LS-ADAT its receiving a different clock, and the AES16 its in internal clock, the pitch becomes unstable.

pitch becomes 2cents unstable at lower buffer size settings.

make a loop test... with a 1 minute 440Hz sine wave and AP Tuner 3.08 (use the zoom in the graphic window.)

Lynx clock sounds better than RME clock.
but... only if the motherboard has clean power and HPT (High Precision Timers) Active in the BIOS.
when looking the Lynx Mixer, theres a PCI measurement 33.3MHz, or 33.4MHz, if its stable... has HPT Active, if has jitter, does not, and the Lynx clock sounds worse.
Old 28th March 2010
  #14
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by Dubai View Post
What OS do you have? x32 or x64?
what motherboard ?
what CPU ?
Sharing IRQs ?

my Lynx AES16 works great, if i select 16-Bit colors in the video card, because its sharing IRQs.
newer X58 motherboards cannot select IRQs manually.
with the older board Asus P5W DH Deluxe, not sharing IRQs, was a dream.

Windows XP MCE 32-Bits, 3GB Ram.
the problem has been replicated across multiple machines -- currently, an x58 mobo (p6t v2), i7 950, w7x64, no shared IRQ's of significance. but IRQ sharing is not nearly the issue it used to be.

but, like i said, its a firmware/driver issue because i have found combinations of older versions that work with the lynx, mostly. its just the newer stuff thats an issue (and by newer i mean the past couple of years). the problems are acknowledged by lynx, just not fixed. but, magically, i plug in the RME and it just works
Old 28th March 2010
  #15
Lives for gear
 
valis's Avatar
If you're having to switch to 16 colors to reduce bus traffic to the graphics card port and are on Xp32, you should give DoubleDawg a shot. Just lower the PCI Latency setting of the gpu to something lower than Lynx/RME (say 64 instead of the 254 or so of the default) and the audio card's buffers should have less issues being 'stepped on' by the gpu's drivers.

Also fwiw modern hardware under Win7 will give you a dramatically different ACPI hardware table, meaning your sharing issues may go away in the event that you update to 64bits someday.
Old 28th March 2010
  #16
Lives for gear
 

Cool

Quote:
Originally Posted by glissando View Post
You have to be careful of assuming that IMO...I don't like PT, but at this point I think it has an edge in the latency department...simply because running sessions at 64 or 32 buffer is unrealistic after some heavy editing...which is par for the course these days...and using a virtual mixer like total mix is useful, but it is still an extra step that can get convoluted...

That being said, I have no problem working at 128 or using a virtual mixer for near zero latency...I can make a record just fine with that, just as long as the system and the card are firing on all cylinders...hopefully the aurora will provide me with that.
Sonic Core Xite-1 DSP mixer its much better than Protools HD DSP mixer.
Old 28th March 2010
  #17
Lives for gear
 

Cool

Quote:
Originally Posted by valis View Post
If you're having to switch to 16 colors to reduce bus traffic to the graphics card port and are on Xp32, you should give DoubleDawg a shot. Just lower the PCI Latency setting of the gpu to something lower than Lynx/RME (say 64 instead of the 254 or so of the default) and the audio card's buffers should have less issues being 'stepped on' by the gpu's drivers.

Also fwiw modern hardware under Win7 will give you a dramatically different ACPI hardware table, meaning your sharing issues may go away in the event that you update to 64bits someday.
yes, i do have lower PCI Latency in the BIOS, 64 works ok, 32 seems too fast.
128 seems ok, more seems too slow.

changing the pci slot also changes the IRQ,
but i have all other slots occupied,

changing the video card from the 1st PCIe slot, to the last PCIe x16 compatible slot also helps a lot.
any card closer to the CPU works better.

dont want to try x64 because DirectX plugins dont work.
but im tempted to instal Vista, just because the time saving file overwrite warning, and the mini window when stepping on top another window in the Taskbar, very useful features.
Old 28th March 2010
  #18
Lives for gear
 

Cool

Quote:
Originally Posted by thedigitalgod View Post
RME
buffer.....samples........ms.......reaper.........RME
32..........280............3.17......0.3/1.1........0.7
64..........344............3.90......0.7/1.4........1.5
128........472............5.35......1.4/2.2.........3
256........728............8.25......2.9/3.6.........6
512........1240..........14.05.....5.8/6.5.........12
1024.......2264..........25.66....11/12............23
*2048....*4312........*48.88....*23/23........*46
*4096....*8408........*95.32....*46/47........*93

Lynx
buffer.....samples........ms.......reaper......... Lynx
32..........215.............2.43.....0.7/0.3.........0.36
64..........279.............3.16.....1.4/0.7.........0.72
128........471..............5.34.....2.1/1.4........1.45
256........727..............8.24.....3.6/2.9........2.9
512........1239............14.04....5.4/5.8........5.8
1024.......2263............25.65...12/11..........11.6

RME has hidden safe buffer, and Auto buffer size... if detects too much CPU usage, the buffer size jumps automatically to 1024 or more.
Old 28th March 2010
  #19
Lives for gear
 
thedigitalgod's Avatar
 

really? thats new stuff to me. do you have a link providing details on this? it would be appreciated
Old 28th March 2010
  #20
Lives for gear
 

Cool

Quote:
Originally Posted by thedigitalgod View Post
really? thats new stuff to me. do you have a link providing details on this? it would be appreciated
in the .txt file that comes with RME hdsp9632 Drivers.
also in web reviews like FireFace800 in Soundonsound mag.

FF800 has different hidden safe buffer size, is +48samples in +48 out.
the hdsp9632 has +32 samples only at input.

the Auto-Buffer sometimes its so annoying. (RME has another name for it, cant remember it.)
was introduced when RME decided to remove the 8192 sample setting in the hdsp9632, and replace it with a 32 sample setting.
Soundcard Firmware update was needed #153 or something for hdsp9632.

when doing Firmware updates its a good idea to remove all other cards from the PC.
i had Emu 1820m, and the RME firmware erased the EMU Firmware, i had both soundcards at same time in the same pc.
"it shoudnt happen" was the EMU and RME support answer.
had to wait for Emu to release drivers v2 with included Firmware updater, and everything was ok again, but sold the EMU eventually becouse the converters & clock sound, also the EMU 1010pci card slowed down the PC noticeable.
Old 28th March 2010
  #21
Lives for gear
 
thedigitalgod's Avatar
 

wow, it was in my txt too. my bad
Old 28th March 2010
  #22
Lives for gear
 
valis's Avatar
Quote:
Originally Posted by Dubai View Post
yes, i do have lower PCI Latency in the BIOS, 64 works ok, 32 seems too fast.
128 seems ok, more seems too slow.

changing the pci slot also changes the IRQ,
but i have all other slots occupied,

changing the video card from the 1st PCIe slot, to the last PCIe x16 compatible slot also helps a lot.
any card closer to the CPU works better.

dont want to try x64 because DirectX plugins dont work.
but im tempted to instal Vista, just because the time saving file overwrite warning, and the mini window when stepping on top another window in the Taskbar, very useful features.
Setting the PCI Latency in your BIOS merely gives an overall default, when drivers load within windows they can (and usually do) set their own priority level. GPU drivers are famous for using values in excess of 250 to maximize fps for gamers, and while I don't have issues on any post 2008 system I own I do remember the days well of adjusting my AGP & PCIe card latencies manually to prevent issues with my DSP cards (Scope).

As far as x64 vs. x32, Vista/Win7 even in their 32bit variants both do support modern APIC/ACPI tables with less issues in regards to IRQ conflicts. I'm not necessarily advocating you move your current system though, just providing info for future reference. Aside from compatibility issues that will need to be vetted with plug-ins, software & hardware you also need to know that even newer ACPI table support is still dependant on your hardware's APIC controller (bios revisions can improve things here btw), and fancy software ACPI stacks still won't affect bus bandwidth issues (which PCI Latency settings help allocate bus bandwidth where you want it) as this is dependant on your current system's hardware.

On Xp32 a Matrox card used to be a great way to avoid bus bandwidth issues as well (much better desktop optimization and typically used a PCI priority of 32-64) but I can't recommend one new as I've lost contact with how their modern offerings are.
Old 29th March 2010
  #23
Lives for gear
 

Cool

Quote:
Originally Posted by valis View Post
Setting the PCI Latency in your BIOS merely gives an overall default
that merely is the difference between working and not working.
PCI Latency its the time the CPU cycles to see if the PCI its used or not, and give priority to other PCI devices,
but if asks too much/fast/often does not allow PCI devices to work, and if does not ask enough often, PCI devices bottle neck the CPU.

Quote:
Originally Posted by valis View Post
when drivers load within windows they can (and usually do) set their own priority level.
if they load....
...not my experience with WinXP MCE.
if the PCI Latency in the BIOS is wrong, the PC starts to behave differently, and becomes unstable.

ACPI almost always shares the IRQs in WinXP MCE x32.
have installed Windows a million times to know if always the same, IRQ6.

ACPI lets windows to decide whats best for the BIOS.
thats one of the reasons i want to try Vista x32 or W7 x32.

i think its time to move to Vista.
Old 29th March 2010
  #24
Lives for gear
 
tazman's Avatar
 

Dumb question... Why did you drop the cash on the RME if the older drivers worked? What they added with the newer ones is not groundbreaking. I guess some people have to have the latest, but if you are doing music and the system works, why mess with it? Having the latest drivers is only a good thing if they give you something that is more than what you already have. Obvioulsy in your case they didn't so why not use the cash for some nice pres or mics and use the older drivers? Just a thought!?!

Quote:
Originally Posted by thedigitalgod View Post
the problem has been replicated across multiple machines -- currently, an x58 mobo (p6t v2), i7 950, w7x64, no shared IRQ's of significance. but IRQ sharing is not nearly the issue it used to be.

but, like i said, its a firmware/driver issue because i have found combinations of older versions that work with the lynx, mostly. its just the newer stuff thats an issue (and by newer i mean the past couple of years). the problems are acknowledged by lynx, just not fixed. but, magically, i plug in the RME and it just works
Old 30th March 2010
  #25
Lives for gear
 

I've got to say I've had lot's of problems with Lynx drivers, too. The firewire interface for the Aurora was a disaster, tried several mainboards and FW cards, it didn't ever work properly.
Now I've got an AES16 and an AES16e, and it's still lot's of trouble. They should hire some clever hardware/software people IMO, updates take way too long, and they tend to blame the user. They had some serious issues in their beta releases (wrong I/O addressed etc.) and it took months to fix. That's just not good enough for a 5000 $ system.
I'd like to switch to RME (where the drivers have always been great), but then I'd loose some functionality with the Aurora.
Since I'm mostly working OTB with a console now the latency problems aren't that relevant anymore. Mixing ITB with lot's of outboard via Reainsert was a nightmare though, with latencies jumping all over the place all the time, and the CPU usage going through the roof.
Old 30th March 2010
  #26
Lives for gear
 
DontLetMeDrown's Avatar
 

Quote:
Originally Posted by tazman View Post
I guess some people have to have the latest, but if you are doing music and the system works, why mess with it? Having the latest drivers is only a good thing if they give you something that is more than what you already have.
I just thought I'd chime in and mention that I installed the newest drivers for my AES16e and new firmware last week even though it didn't seem like there was much for me to gain. My system was working fine before (ver16, fw7), but after the update it seems even better despite the ridiculous i/o GUI.

Running the buffer at 32 is not so sensitive to dropouts like the old drivers were. I'm recording a rock project right now-- so far we've tracked drums, rhythm guitars (double tracked), vocals and voc doubles. With the buffer at 32 the project runs at 10-15% cpu on my i7 965 system. That even includes some Soundtoys FX sends on the vocals and UAD plate 140 snare verb just for some tracking fun. 1.8 msec latency, 2.9 msec roundtrip. The computer could pull it off before, but there would be random glitches, but not anymore.
Old 30th March 2010
  #27
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by tazman View Post
Dumb question... Why did you drop the cash on the RME if the older drivers worked? What they added with the newer ones is not groundbreaking. I guess some people have to have the latest, but if you are doing music and the system works, why mess with it? Having the latest drivers is only a good thing if they give you something that is more than what you already have. Obvioulsy in your case they didn't so why not use the cash for some nice pres or mics and use the older drivers? Just a thought!?!
because i cant use multiple cards reliably with the working combination i found, which im not doing now, but plan to in the near future. and i was using drivers that are 2 versions old in order to make it work at all. what happens when i update something else and the card wont work at all because im having to use old drivers that arent even made for the OS im running? i simply lost faith in them after so much time and so little progress when many users were having the same issues and they essentially ignored the problem. so i replaced it with the RME, im going to run it for a few weeks to make sure there are no surprises (which i dont anticipate because it has been liquid thus far), and then sell the AES16e.
Old 30th March 2010
  #28
Lives for gear
 
tazman's Avatar
 

Good luck then. I hope the best for you..thumbsup

Quote:
Originally Posted by thedigitalgod View Post
because i cant use multiple cards reliably with the working combination i found, which im not doing now, but plan to in the near future. and i was using drivers that are 2 versions old in order to make it work at all. what happens when i update something else and the card wont work at all because im having to use old drivers that arent even made for the OS im running? i simply lost faith in them after so much time and so little progress when many users were having the same issues and they essentially ignored the problem. so i replaced it with the RME, im going to run it for a few weeks to make sure there are no surprises (which i dont anticipate because it has been liquid thus far), and then sell the AES16e.
Old 30th March 2010
  #29
Lives for gear
 

Exclamation

Quote:
Originally Posted by DontLetMeDrown View Post
I just thought I'd chime in and mention that I installed the newest drivers for my AES16e and new firmware last week even though it didn't seem like there was much for me to gain. My system was working fine before (ver16, fw7), but after the update it seems even better despite the ridiculous i/o GUI.

Running the buffer at 32 is not so sensitive to dropouts like the old drivers were. I'm recording a rock project right now-- so far we've tracked drums, rhythm guitars (double tracked), vocals and voc doubles. With the buffer at 32 the project runs at 10-15% cpu on my i7 965 system. That even includes some Soundtoys FX sends on the vocals and UAD plate 140 snare verb just for some tracking fun. 1.8 msec latency, 2.9 msec roundtrip. The computer could pull it off before, but there would be random glitches, but not anymore.
#1.
can you make the 440Hz pitch test with AP Tuner 3.08 ?
just generate a 1 minute sinewave at 440Hz.
use WindowsMedia Player--->AES/EBUout4--->AES/EBUinput4--->AP Tuner 3.08

open the graphic window in AP Tuner and zoom horizontal and vertical to see if thers any pitch problem with 32samples of buffer size,
if you have problems, you can also test other buffer sizes. but to change the buffer size, you must close all audio programs, change the buffer in the Lynx mizer and then open again the softwares, (also: allow clock change if active, <--must be activated in the Lynx mixer, and SynchoLock(TM) Disabled,)
to see if you have pitch problems at 32/64/12/512 buffer sizes.

AP Tuner for Windows
...
alternative you can use Cubase/Sonar/etc.. with ASIO drivers, and a Free MDA VST plugin, TestToneGenerator to make the 440Hz signal.

mda-vst.com

when doing the Pitch test, if you have LS-ADAT, and you have different clocks, all clocks must be the same,
for example: if the ADAT input has a different clock from any ADAT signal, and the Lynx Mixer is selected to a different clock: Internal/Ext/AES
and both clock signals are not the same (not a masterclock), the Lynx AES16 pitch problems will increase.
if usign internal AES16 clock you must disconnect any different clock coming to the LS-ADAT inputs.


#2.
can you see if your Lynx soundcard is sharing IRQs?

to see that in Vista or W7:
click (START) the windows logo, or the Windows Key in the Keyboard.
in: {Start Search}
type: msinfo32
press the keyboard key: enter<---
...wait 1 second until the software loads/analyze the PC.
then click: (+)HardwareResources
and click: [IRQ]

in the right windows look for the Lynx driver IRQ number, then see if other devices have the same IRQ number (sharing IRQ).
Old 30th March 2010
  #30
Lives for gear
 
thedigitalgod's Avatar
 

Quote:
Originally Posted by Dubai View Post
can you make the 440Hz pitch test with AP Tuner 3.08 ?
just generate a 1 minute sinewave at 440Hz.
use WindowsMedia Player--->AES/EBUout4--->AES/EBUinput4--->AP Tuner 3.08

and use the graphic window, and zoom horizontal and vertical to see if thers any pitch problem with 32samples of buffer size,
also test other buffer sizes.
...
alternative you can also use Cubase/Sonar/etc.. with ASIO drivers, and a Free MDA VST plugin, TestToneGenerator to make the 440Hz signal.
now thats interesting. is there known to be an issue with pitch at lower buffer settings on the lynx or any other card?
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Similar Threads
Thread
Thread Starter / Forum
Replies
Killah_Trakz / Rap + Hip Hop engineering and production
12
dolo / Music Computers
0
eliottjames / So much gear, so little time
0
Buddhaman / Gearslutz Secondhand Gear Classifieds
0

Forum Jump
Forum Jump