Good afternoon gents, I am building up a server with basically a solid state drive for the OS and a 1 TB hard drive for the datas. In order to maximize the life time of the SSD, I will avoir mounting slides that sustain continuous or sparsed write access. Could you briefly let me know the do's and don't ? Thanks. Jean-FranC'ois
Yeah; ignore dos and donts the ssd, if of any quality, will do fine. On May 22, 2010, at 10:03 AM, jean-francois <email@example.com>
That has been my experience with SSDs on OpenBSD and Linux. I've been using an inexpensive Kingston SSD for about six months now, it works great. Here is an older dmesg from it:
On Sat, 22 May 2010 17:03:12 +0200 keep everything at multiples of eraseblock-size of your drive. eraseblock-size on most ssds is 512k, some use 128k. start the partition (offset) at 2048 sectors / 1mb dont use the full drive, only for example 90%, this will make the ssd live longer, but it might be obsolete before it dies anyway. again inside the partition make slices multiples of eraseblock-size big. dont use disklables unit conversion for this, calculate the sector size on your own. and yes, under load all that manual alignment stuff makes a difference in speed and longlivity of the drive.
I have a large amount of analog audio I need to digitize and naturaly want to ensure best transfer quality. So I need to set the analog level at the input to the adc as high as possible without clipping. Ideally, I'll get the workstation hardware set to certin defaults, then adjust the incomming audio as required. This leads to a couple of questions: Are there (typicaly) any variable gain stages in the analog input path in the computer. Mixerctl -av (full output below) shows a node called 'record.adc'. It seems reasonable that this might opperate on the analog input to the adc. However there is also 'record.volume', though I would assume this operates on the mixed digital signals at the end of the chain. Also: a lot of the gain stages have defaults of 120.120. Would it be reasonable to assume that this is the 0 gain setting? Any thoughts appreciated. paulm molly:/home/paul >mixerctl ...
Hi, this you might already know, but good rule of thumb is to set the levels manually for each source (according to its dynamics), having peaks around -6dB to -10dB. If you have manual volume/gain control on your recording device/preamp, I'd set all levels in the computer to 80% of the scale and then control everything by hand, on the box. This probably doesn't apply to OpenBSD, but in Linux there have been serious distortion trouble with levels set to 100% on some older cards - the only solution is AFAIK try it out and use what your ears tell you. The good news is you can do other stuff while your LP's spinning and recording :-) -- Martin Pelikan
varies depending on hardware, but often there is a gain no. record.volume is essenially an alias. on your hardware with the configuration you've posted, it's a shortcut for setting both record.adc and record.adc2. this is explained in azalia(4) (though maybe that info didn't make it into 4.6, the info in -current azalia(4) no. unfortunately, the mixer interface, like a lot of audio(4) related stuff, is designed for "consumer usage". so, we just have a range that is essentially 0-100% - it has no relevance to anything except the knob. truly the worst kind of knobs are those that have no outside meaning, but apparently people like this. *shrug* if you really want to know how to do this right, your best bet is to find the datasheet for your codec. now, your codec is a Realtek, which is common for azalia(4), and this is a 0 (0), 10 (85), 20 (170), 30 (255) dB gain on the line-in this is the ADC input gain. 0 dB should be around '88'. 0..255 here represents the hardware's -16.5 to 30 dB in 1.5 dB steps. these are the only gains on the recording path of your device. -- firstname.lastname@example.org SDF Public Access UNIX System - http://sdf.lonestar.org
Looking at the mixerctl output again, this does appear to be the Thanks Jacob, this is gold. I'll try and find that datasheet, but what you've given me here is probably enough for me to work out what I need. Thanks again, and thanks to all who worked on giving the audio subsystem the openBSD love. paulm
It is good practice to leave a little headroom (say, 6dB) for further processing. You might want to do some noise reduction, compressing, whatever, and the effects will clip if the signal already is saturated. Also, "the input to the adc" is not all there is to it; there are other mixer settings that affect the signal There are no "defaults". Your analog inputs can Yes. 'mixerctl -a' will shouw you how the azalia 'widgets' are record.volume What's a "0 gain setting"? I believe Jacob Meuser has work going on to make the numbers on the azalia knobs correspond to actual decibels, It would be my guess that this is the audio chip that's integrated with the Asus P5QPL-AM motherboard. If you are really after "best transfer quality", you might want to use something else in the first place.
I'll leave enough headroom to allow for the highest peaks, but I'm not planning on doing any additional processing during the initial conversion. I can attenuate the signal later if I add I dont really want to futz with the audio hardware once it's set up, so these 'defaults' would be such that a certain input signal level will produce a clean digital file with no clipping and good dynamic range. I'll then use a preamp with decent VU meters Unity gain, or 0dB gain. Signal level out = signal level in (for Good point, thanks for the reality check. Most of what I have to do is not the best quality anyway, but that doesn't mean I'm happy to introduce unnecessary generation loss by being sloppy. There is some though that is very good, so that may well need something better. paulm
I heard the Griffin iMic was to be discontinued, but mine is supported under OpenBSD. Your best bet for clean audio is a USB-attached device. Sound cards just get too much noise off the motherboard.
Interesting. I have one of those kicking around somewhere. I'll have to dig it out. Thanks paulm
well, it depends on the sound card; properly engineered cards don't get noise, including pci ones. -- Alexandre
Are some of them known to be better then others in this respect?
any card that claims >100dB S/N should be ok, assuming the vendor is not lying. I've a m-audio delta 1010lt, and a esi julia that don't get noise while they are plugged on a machine I use as a wireless access point (which btw is probably the most stupid setup). -- Alexandre
It seems the best I can get with the built-in sound on this computer is about 36dB S/N. If the various input gain stages are not set quite carefully, it gets much worse. Rf pickup in the input leads is high too. paulm
that's not very good; 8-bit samples correspond to 48dB; I mean with 48dB S/N, only 8 higher bits are significant. Such a low S/N ratio makes me wonder if your cables, power supply or whatever are ok. BTW, how did you measure the S/N ratio? -- Alexandre
No, it's not. I measured by writing samples to a file then examining the file. For a source, I used a 440 Hz sine wave. With all the input gains set to minimum, the noise was negligible (< -60 db, which is the smallest I could measure). This is pretty much just the noise of the chip itself. I then tweaked the various input levels (preamp, input stage, adc) till the output of the preamp was just below clipping of the first input stage, and the samples in the file were also just below clipping. This gave me my signal level. Then I disconnected the input and repeated, this gave me my noise - shorting the input may give better results. I repeated this over and over to find the best balance between input stage gain and adc gain. I found the best result was to set the input stage as low as possible, and adjust the adc gain to give full output. (dont forget the input signal is as high as it can be without clipping) Update: Today I reduced the input gain stage to 0 (I didnt try this yesterday) and got about another 6-8 dB, so now I'm < 50 dB. Jacob mentioned in and earlier mail that '0' for the input stages on this codec is 0dB gain. FWIW the adc gain is set to 96 (+12dB). Since my moise is measured with no input connected, this rules out any external problems such as cables. The power supply in the computer may be moisy, but I would guess that crappy circuit layout is more likely. (though I will try another power supply some time and see if it helps) paulm
I have worked with audio before, and can confirm internal audio codecs are very good for... trash them. If quality is of any concern for you, just try another adapter, i.e. an inexpensive Behringer UCA 202 USB audio interface. I've tried it with great results on OpenBSD, and you can buy it in Europe for as low as 27eur in Thomann. Regards, and good luck. I've a PMR/O
On Sat, 22 May 2010 17:03:12 +0200 Oh and here, dont try to be clever or worry too much, just use it like rotating rust drives.
DO install everything normally. DO NOT bring up the non-issue of SSD's dying if you "mount slides that sustain [something]" (whatever that means) on mailing lists.
|Greg KH||Og dreams of kernels|
|Jens Axboe||[PATCH 31/33] Fusion: sg chaining support|
|Arnd Bergmann||Re: finding your own dead "CONFIG_" variables|
|Mark Brown||[PATCH 2/2] Subject: natsemi: Allow users to disable workaround for DspCfg reset|
|Tony Breeds||[LGUEST] Look in object dir for .config|
|Brian Downing||Re: Git in a Nutshell guide|
|John Benes||Re: master has some toys|
|Matthias Lederhofer||[PATCH 4/7] introduce GIT_WORK_TREE to specify the work tree|
|Alexander Sulfrian||[RFC/PATCH] RE: git calls SSH_ASKPASS even if DISPLAY is not set|
|Junio C Hamano||Re: Rss produced by git is not valid xml?|
|Linux Kernel Mailing List||iSeries: fix section mismatch in iseries_veth|
|Linux Kernel Mailing List||ixbge: remove TX lock and redo TX accounting.|
|Linux Kernel Mailing List||ixgbe: fix several counter register errata|
|Linux Kernel Mailing List||b43: fix build with CONFIG_SSB_PCIHOST=n|
|Linux Kernel Mailing List||9p: block-based virtio client|
|Michael Breuer||Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit()|
|Michael Breuer||Re: [PATCH] af_packet: Don't|